Делать нельзя думать. Или ревизия «хотелок» на старте ИТ-проекта
Хочу я, например, автомобиль Bugatti Super Sport 300+. Самые крутые ведь на нем ездят. Допустим, накопил. Купил. И тут вспомнил, что самый частый мой маршрут – это дом-дача-дом. Дорога лесом-полем. Надо ли уточнять, что Bugatti по русским деревенским буеракам не проедет? Пришлось дорабатывать лошадку – из низкой посадки высокую делать. Копил на это еще пять лет. Доработал. Доехал до дачи. Накопал картошки. А грузить-то некуда… не умещаются… Опять копить на тюнинг? Или может быть уже осознать, что не ту машину я выбрал? Отличный агрегат, но не для моих целей.
Думаете, так только с машинами бывает? Вообще нет.
История стара как мир: взяли продукт, у которого «фантик краше», стали внедрять, и через пару месяцев/полгода /год – кому как повезет, (когда бюджет безвозвратно утрачен, а результат еще даже на горизонте не виднеется), выяснили, что ну не тот продукт нужен был. И тут два варианта: или таки продолжать допиливать (читай «сливать бюджет в бездонный колодец»), или отступиться, выбрать то, что подходит и начать сначала (скупой платит дважды).
И как быть? Расскажем обязательно. В рамках блиц-интервью с нами поделился опытом руководитель производства сети пекарен «Хлебник» Александр Васильев.
Примечание: мы умышленно не будем называть программный продукт, который был использован для реализации проекта, потому что это не имеет значения в данном случае. Нет плохих и хороших продуктов. Есть продукты, подходящие или нет под решение конкретных задач.
Задача «обследования» в данном случае была явно не выявить особенности учета и потребности данного предприятия, а определить список настроек для заранее выбранного решения.
При таком подходе к сбору информации о клиенте на старте и невозможно было предложить адекватное решение
Если интегратор этого не делает – это тревожный звоночек.
ПОДЫТОЖИМ
Смысл предпроектного обследования – выявить ОПТИМАЛЬНЫЙ способ достижения целей предприятия. Выбрать не тот продукт, который может ВСЕ, а тот, который может именно ТО, ЧТО ВАМ НУЖНО.
Поэтому сначала надо понять, для чего мы делаем проект – проанализировать реальные потребности предприятия, определить задачи проекта, и только потом выбирать способ их решения – конкретный продукт или набор продуктов, а не наоборот. Наоборот будет долго, дорого и нерезультативно.
Как вы уже поняли из рассказа моего соавтора, обследование обследованию рознь. План внедрения конкретного ПО – это вообще не обследование.