Внедрение комплексной системы автоматизации. Как сделать по уму и не наступить на грабли

Проект внедрения состоит из нескольких этапов.
Гарантия успешного внедрения (она же основной признак ответственного внедренца) — способность беспощадно отсекать сомнительные затеи на КАЖДОМ этапе, НЕ боясь потерять клиента.
Ибо "лучше с умным потерять, чем с дураком заработать".

Рекомендуемая Ultimate
- и партнерам,
- и клиентам
схема работ по типовому проекту внедрения решения состоит из следующих крупных этапов:

0. Знакомство

Все начинается с того, что вы оставляете заявку на сайте. Сообщаете что-то типа «вау, нас заинтересовало, давайте встретимся, вы нам все расскажете».

Однако сначала рассказывать придется вам: встреча проходит в формате «вы говорите, мы слушаем».

Вы: рассказываете о своем бизнесе, о своих проблемах — почему обратились, что не устраивает в текущей ситуации, желаниях — что вы хотите получить. Чем больше конкретики — тем лучше.
Мы: слушаем, задаем уточняющие\наводящие вопросы, НЕ рассказываем (и НЕ показываем) ничего.

Основные наши задачи на этом этапе — получить представление об:

  • основных бизнес-процессах предприятия — собственно, что за бизнес и как он работает;
  • рациональности и принципиальной достижимости целей заказчика (в том радостном случае, если оный в принципе в состоянии их внятно сформулировать)
  • вменяемости decision-makers заказчика, и, в целом, вероятной работоспособности предполагаемой схемы управления проектом, с учетом трений и личностных противоречий (если есть) между стейкхолдерами оного со стороны заказчика.

Короче, если сложить одной строчкой — детектировать явных фриков с завиральными мегаломаниями
и/или интриганские паучные банки, отфильтровав тем самым заведомо провальные затеи.
Как известно, «лучше с умным потерять, чем с дураком заработать», а развернуто об этом в соответствующей статье «Какие клиенты нам не нужны».

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

P.S. Отдельно стоит осветить подкласс интересующихся, которые в инициирующем обращении предлагают «приехать провести презентацию программы».

1. Преданализ

Если полученные впечатления после этапа 0 — «Знакомства» — устроили
И нас,
И потенциального заказчика,
работа по (все еще потенциальному) проекту переходит на следующий этап: «Преданализ».

Если, в целом, на этапе знакомства мы разбирались, что у вас за бизнес и как он работает сейчас, то на этапе преданализа мы договариваемся о едином видении, что же должно получиться в итоге.
То есть — как будет выглядеть и работать ваш бизнес после успешного внедрения IEM-системы Ultimate (так называемая "модель to be").

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

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

Расширяя континуум аналогий, — что вы хотите получить на выходе? Детскую коляску? Яйцеварку? Подводную лодку?
Не вопрос.
Проблемы начинаются, если вы хотите получить ложку для обуви, оснащенную ядерными МБР.

Что мы делаем на этом этапе (везде ниже речь идет о состоянии to be):

  • договариваемся, как будут работать в целом основные бизнес-процессы автоматизируемого предприятия. Основные — это те, которые формируют добавочную стоимость (и только они).
  • определяемся с основными ролями (эквивалент в традиционной бюрократической логике штатного расписания — должностями) и их функционалом — «кто что делает». Основные роли — участники основных бизнес-процессов.

Чего мы НЕ делаем на этом этапе: всего остального.
Мы НЕ погружаемся в детали, НЕ обсуждаем технические вопросы и будущую организацию второстепенных бизнес-процессов.
Это все очень важно, но — НЕ главное. Детали проясняются на следующем этапе — «Техническое задание».

Преданализ — не то, чтобы самый важный этап (что в доме важнее — стены или крыша?), но, несомненно, при должной отработке — наиболее интеллектуально нагруженный.
Мы несильно погрешим против научной точности, если приравняем этот этап к реинжинирингу бизнес-процессов.

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

В случае подключения на этом этапе Ultima Consulting (что партнерам Ultimate рекомендовано делать, со своей стороны, для всех нетиповых проектов), такие неожиданности являются скорее правилом.

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

В случае же, когда существенные расхождения зафиксированы, то возможны варианты:

  • ежели несомый потенциальным заказчиком бред не жизнеспособен ни при какой ситуации (как правило, заболевание протекает на фоне русско-барственного самодурства, интергалактического ЧСВ и зашкаливающего градуса неадеквата), то отношения естественным образом завершаются. Продолжая аналогию с врачом и пациентом, если пациент не согласен с диагнозом, как может идти речь о результативном лечении? Обратитесь к другому специалисту.
  • ежели потенциальный заказчик настаивает на включении в модель to be неких дурь-артефактов, не влияющих однако на успешность затеи в целом (под это определение попадают как совершенно безвредные (сколь и бесполезные) свистелки и перделки, зело прельстивые сердцу собственника, так и явно вредительские, но немасштабные измышления), то мы (как правило) делаем как хочет клиент.
    Но, при этом, по каждому дурь-артефакту фиксируем свое “особое мнение” и предсказания исхода в формате disclaimers в тексте Технического задания (см. следующий этап). Пациент просит врача — христа ради допишите в рецепт настоечку спиртосодержащую, пожалуйста, ну чего вам стоит. Жена сильно против, а тут для здоровья от врача, не поспоришь! — Ладно, больной, вот вам еще три пузырька тут допишу, но только вы не слишком там злоупотребляйте!

Вся наша деятельность в рамках этапа «Преданализ» — совершенно бесплатна.

Продолжительность, в зависимости от сложности случая, от недели до месяца.

Типичный комплекс мероприятий, помимо общения с decision-makers со стороны потенциального клиента, предполагает серию встреч-интервью с руководителями основных (в смысле, определенном выше) функциональных подразделений предприятия, наблюдение за работой оных (“хождение в гембу”) и, в ряде случаев, интервью с линейными сотрудниками — кандидатами на исполнение основных ролей в модели to be.

2. Написание и утверждение Технического задания

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

ТЗ — документ, четко и исчерпывающе описывающий деятельность предприятия в состоянии to be в абстракции IEM.
Иными словами, в ТЗ описывается, ЧТО система должна делать — а не КАК она будет устроена или КАК это будет делать.
ТЗ — аналог чертежа детали, а не описание предполагаемых действий фрезеровщика по ее изготовлению.
Образцово написанное ТЗ инвариантно по отношению к внедряемой системе.

Техническое задание содержит:

  • строгое описание имплементируемых бизнес-процессов — всех: как основных (обсуждавшихся на этапе «Преданализ»), так и второй важности (бэкофис, грубо говоря);
  • перечень бизнес-объектов и их свойства;
  • перечень отчетов и их свойства;
  • роли пользователей и их права.

Техническое задание НЕ содержит любимого повода для многочасового сцепления языками для регулярно встречающихся среди представителей заказчика типажей: описания экранных форм, где какие галочки и какого цвета кнопочки.
Характерно это явление, в первую очередь (но не ограничиваясь) для самодурно (=плохо) управляющихся предприятий, обсуждение кнопочек для сотрудников которого является редким случаем почувствовать (хоть какую-то) собственную значимость и влиятельность. Сочувствуем, парни, но — мы тут не помощники.
Еще раз повторяем: эргономика рабочего места невероятно важна, но обсуждается она и (правится на лету) в процессе обучения именно тех пользователей, которым с ней работать.
В некоторых случаях, когда это реально необходимо, по особо сложному и чувствительному функционалу оформляется Техническая спецификация (ТС), которая идет приложением к ТЗ.

Почему “Технического” с большой?
Потому что это самый важный документ.
Он определяет project scopes — что надо сделать — из чего, соответственно, вытекают и сроки, и деньги.
Еще раз другими словами: содержание Технического задания на 100% определяет будущий функционал системы. Если там что-то не упомянуто, то, вне зависимости от типа “самоочевидных” ощущений заказчика, это делаться не будет.

Точнее делаться-то может, но — за отдельные деньги и сверхлимитное время.

Caveat emptor, как бы намекают нам древние римляне. Знавшие толк как в коммерции, так и в менеджменте сложнейших проектов.
Так что читайте внимательно и не раз, обсуждайте, спорьте, правьте. В противовес часто встречающемуся «да ладно, парни, все нормально, погнали наконец делать, потом если чо разберемся».
Тут лучше подумать лишнюю неделю, да сэкономить “потом” куда больше. В том числе сложновосстанавливаемых нервных клеток.

Стоимость изготовления ТЗ обычно порядка 10–15 тыс. евро, из которых половина — платится ДО, а половина — после утверждения заказчиком. Стоимость ТЗ входит в общую стоимость работ по проекту, которую вы видите в конфигураторе.

Длительность изготовления ТЗ, как правило, от двух недель до двух месяцев.

3. Выставление коммерческого предложения

После утверждения ТЗ мы калькулируем деньги и сроки, и выставляем оное коммерческое предложение. В котором содержится количество лицензий и компонент Ultimate, объем работ, разбитых на этапы (при наличии), стоимость и длительность каждого этапа, предполагаемый график платежей, спецификация аппаратной части системы (закупается заказчиком самостоятельно).

Устраивает?
Поехали.
Подписываем весь комплект договоров, берем гарантийный аванс (как правило, 30% от стоимости работ по внедрению — НЕ всего проекта).

4. Собственно работа по проекту

Несколько месяцев работают программисты и аналитики, обучаются пользователи, рисуются сайты, поставляется и настраивается hardware, разворачивается Oracle и Ultimate, настраивается автоматический перенос данных из старой системы.
А также прочие хозяйственные хлопоты.
Трудоемко, часто геморройно, но, в сущности, тривиально.

5. Запуск в эксплуатацию

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

6. Окончательный расчет

Стулья в наличии, время для денег.

Другие материалы из Библиотеки атеиста


Powered by Сон разума