Делать нельзя думать. Или ревизия «хотелок» на старте ИТ-проекта

Начнем с риторического вопроса: всегда ли нам нужно то, чего мы хотим? 

Хочу я, например, автомобиль Bugatti Super Sport 300+. Самые крутые ведь на нем ездят. Допустим, накопил. Купил. И тут вспомнил, что самый частый мой маршрут – это дом-дача-дом. Дорога лесом-полем. Надо ли уточнять, что Bugatti по русским деревенским буеракам не проедет? Пришлось дорабатывать лошадку – из низкой посадки высокую делать. Копил на это еще пять лет. Доработал. Доехал до дачи. Накопал картошки. А грузить-то некуда… не умещаются… Опять копить на тюнинг? Или может быть уже осознать, что не ту машину я выбрал? Отличный агрегат, но не для моих целей. 

Думаете, так только с машинами бывает? Вообще нет. 

История стара как мир: взяли продукт, у которого «фантик краше», стали внедрять, и через пару месяцев/полгода /год – кому как повезет, (когда бюджет безвозвратно утрачен, а результат еще даже на горизонте не виднеется), выяснили, что ну не тот продукт нужен был. И тут два варианта: или таки продолжать допиливать (читай «сливать бюджет в бездонный колодец»), или отступиться, выбрать то, что подходит и начать сначала (скупой платит дважды). 

И как быть? Расскажем обязательно. Но не сами. В рамках блиц-интервью с нами поделился опытом руководитель производства сети пекарен «Хлебник» Александр Васильев. 

Примечание: мы умышленно не будем называть программный продукт, который был использован для реализации проекта, потому что это не имеет значения в данном случае. Нет плохих и хороших продуктов. Есть продукты, подходящие или нет под решение конкретных задач.

Александр, расскажите, каковы были предпосылки входа в проект автоматизации учета? 

Основной целью была возможность принимать объективные управленческие решения здесь и сейчас. Для этого нужно получать данные о работе производства оперативно. На текущий момент мы ведем посмертный производственный учет, т.е. узнаем о реальных результатах только спустя время. С такой системой масштабироваться невозможно (точнее, возможно, но это крайне неэффективно с точки зрения бизнеса). Поэтому решили внедрить автоматизированную систему учета на производстве. Выбрали подрядчика и пошли в проект.

Как проходило предпроектное обследование? Выезжал ли к вам интегратор?

Обследование представляло собой интервью, которое проходило в удаленном формате. Следующим шагом интегратор провел показ выбранного продукта на стандартной демо базе. Как таковой адаптации базы под особенности нашего предприятия проведено не было.

Как позже показала практика, интервью – это не совсем эффективная методика обследования для выбора продукта. Потому что в процессе внедрения перечень доработок стал нарастать как снежный ком.

Комментарий автора: Задача «обследования» в данном случае была явно не выявить особенности учета и потребности данного предприятия, а определить список настроек для заранее выбранного решения. 

А почему тогда было решено выбрать именно этот программный продукт?

У компании, которую мы выбрали в качестве подрядчика, был в опыте схожий проект. Предприятие не пищевое, а строительное, но технология изготовления продукта похожа (изготовление через запекание). Поэтому решили положиться на опыт интегратора и взять продукт, который, по их мнению, нам подойдет. 

Вероятно, интегратор переоценил свои возможности, потому что как на старте не смог показать, так и в ходе проекта не смог реализовать то, что нам нужно. Такого рода опыт, конечно, ценен – мы теперь поняли, как делать не надо. Единственный минус – это потраченные деньги и время.

Комментарий автора: При таком подходе к сбору информации о клиенте на старте и невозможно было предложить адекватное решение.

Как считаете, почему возникли такие сложности?

Основная причина возникших проблем – это недооценка масштаба предстоящих работ на старте. 

Мы взяли продукт, в котором, как принято считать, все зашито. Однако в соотношении с реальными запросами нашего предприятия к функционалу – это как на рыбалку на круизном лайнере ходить. Достигнем ли мы цели? Да. Рыбу поймаем. Но только какими затратами? Может есть другие более подходящие решения?

Если бы мы знали, что процессы, заложенные в логике данного продукта будут так сильно отличаться от процессов нашего предприятия, мы бы, конечно, выбрали другой продукт. 

Что нужно было сделать иначе в рамках предпроектного обследования?

При обследовании в первую очередь нужно изучать специфику и потребности конкретного бизнеса. 

Комментарий автора: Если интегратор этого не делает – это тревожный звоночек.

Каждое предприятие имеет свою структуру. Двух одинаковых бизнесов не бывает. Каждый бизнес проходил свой путь, приобретал свой подчерк, и поэтому внедрение системы тоже требует индивидуального подхода. А это можно сделать только на месте, увидев цепочки продуктовых потоков. Но никак не в формате созвона и интервью. 

Кроме того, обследование – это хороший способ оценить, насколько подходит вам данный конкретный интегратор. Важно найти своего подрядчика. Который вас будет слышать и понимать. Который с вами будет говорить на одном языке. 

Подытожим.

Смысл предпроектного обследования – выявить ОПТИМАЛЬНЫЙ способ достижения целей предприятия. Выбрать не тот продукт, который может ВСЕ, а тот, который может именно ТО, ЧТО ВАМ НУЖНО.

Поэтому сначала надо понять, для чего мы делаем проект – проанализировать реальные потребности предприятия, определить задачи проекта, и только потом выбирать способ их решения – конкретный продукт или набор продуктов, а не наоборот. Наоборот будет долго, дорого и нерезультативно. 

Как вы уже поняли из рассказа моего соавтора, обследование обследованию рознь. План внедрения конкретного ПО – это вообще не обследование.