“CEO создан для счастья, как птица для полета”
М. Горький в предвидении IEM

“Рожденный ползать летать не может”
Он же о перспективах ERP-внедрения

Методология внедрения IEM-систем Или Удовольствие в процессе, прибыль в финале

Если в IEM вы рисуете электронный портрет предприятия в модели to be (это — интересно, это — истинная радость творения), то в случае внедрения ERP-системы, согласно известному анекдоту, вы на протяжении многих лет из букв ж, о, п, а складываете слово "вечность".
Завершение типового “внедрения” ERP совпадает с пронзительным осознанием недостижимости результата. Страус-менеджеры “внедряют” до пенсии или увольнения.

Корректно внедренная IEM-система воплощает кибернетическую модель, являющуюся полной, замкнутой, взаимно-однозначной проекцией реального предприятия во всем его существенно-значащем многообразии.

Если проще — его кибернетическим отражением.

А проект внедрения делится на две части:

  • креативную: собственно рисование портрета (конфигурация цепочек создания стоимости) желаемого состояния предприятия

  • техническую: его трансляцию в пространство бизнес-логики IEM

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

Предпосылкой успешного внедрения IEM является качественно спроектированная модель бизнеса to be. Очевидно, что такая модель НЕ может быть построена без мотивированного вовлечения decision-makers Заказчика.

Если же таковое вовлечение не наблюдается, интегратор IEM обязан отказаться от проекта.

Фазы проекта

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

Вы связываетесь с интегратором IEM-системы. И никогда наоборот: парадигма IEM предписывает работу только с подготовленными заказчиками, и прямо запрещает т.н. “активные продажи”.

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

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

Вы: рассказываете о своем бизнесе, о своих проблемах — почему обратились, что не устраивает в текущей ситуации, желаниях — что вы хотите получить. Чем больше конкретики — тем лучше.

Интегратор: слушает, задает уточняющие\наводящие вопросы. НЕ рассказывает (и НЕ показывает) ничего.

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

  • основных бизнес-процессах предприятия — собственно, что за бизнес и как он работает;

  • рациональности и принципиальной достижимости целей Заказчика

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

Короче, если сложить одной строчкой — детектировать явных фриков с завиральными мегаломаниями

и/или интриганские паучные банки, отфильтровав тем самым заведомо провальные затеи.

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

Кибернетика IEM математически приводит к принципу “win-win”. Интегратор IEM несет как минимум не меньшие риски, чем Заказчик (см. далее), в противовес привычной “игре в одни ворота” с внедрениями ERP-систем.

Если риск проекта, с учетом всех сопутствующих факторов человекообразного характера, признан Интегратором приемлемым, а предприятие Заказчика, соответственно, — пригодным для внедрения IEM, далее переход на следующий этап.

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

Если на этапе знакомства связка “Заказчик-Интегратор” (далее — “мы”) разбиралась, что у вас за бизнес и как он работает сейчас, то на этапе преданализа мы приходим к единому видению, что же должно получиться в итоге.

То есть — как будет выглядеть и работать ваш бизнес после внедрения IEM-системы (модель to be).

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

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

Проблемы начинаются, если вы хотите получить ложку для обуви, оснащенную ядерными МБР.

Что мы делаем на этом этапе:

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

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

Чего мы НЕ делаем на этом этапе: всего остального.

Мы НЕ погружаемся в детали, НЕ обсуждаем технические вопросы и будущую организацию второстепенных бизнес-процессов.

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

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

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

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

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

  • если несомый Заказчиком бред не жизнеспособен ни при какой ситуации (как правило, заболевание протекает на фоне бюрократического самодурства и/или “I am a founder, bitch!”), то отношения естественным образом завершаются. Продолжая аналогию с врачом и пациентом, если пациент не согласен с диагнозом, как может идти речь о результативном лечении? Обратитесь к другому специалисту.

  • если Заказчик настаивает на включении в модель to be неких дурь-артефактов, не влияющих однако на успешность затеи в целом (под это определение попадают как совершенно безвредные (сколь и бесполезные) свистелки и перделки, зело прельстивые сердцу собственника, так и явно вредительские, но немасштабные измышления), то Интегратор (как правило) делает как хочет клиент.

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

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

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

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

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

После того, как мы сошлись в видении, чего же мы хотим получить на выходе, начинается техника.

А именно — разработка и утверждение Технического задания (ТЗ).

ТЗ — документ, однозначно и исчерпывающе описывающий деятельность предприятия в состоянии to be в IEM-абстракции.

Иными словами, в ТЗ описывается, ЧТО управляющая система предприятия будет делать (а не КАК).

ТЗ — аналог чертежа детали, а не технологическая карта предполагаемых действий фрезеровщика по ее изготовлению.

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

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

  • перечень бизнес-объектов и их свойства;

  • перечень отчетов и их свойства;

  • роли пользователей и их права.

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

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

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

Caveat emptor, как бы намекают нам древние римляне. Знавшие толк как в коммерции, так и в менеджменте сложнейших проектов.

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

Тут лучше подумать лишнюю неделю, да сэкономить “потом” куда больше. В том числе сложновосстанавливаемых нервных клеток.

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

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

По согласованному ТЗ Интегратор калькулирует деньги и сроки и выставляет детальное коммерческое предложение.

Относительно ERP-внедрения для той же компании — от 10 до 100 раз дешевле, сроки — месяцы вместо лет.

Заказчик согласен? Поехали.
Модель честного деления рисков запрещает Интегратору IEM брать деньги вперед. При этом, в соответствии с ней же, рекомендуется взимание небольшого аванса в качестве залога серьезности намерений Заказчика.

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

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

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

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

Так или иначе, через месяц работа на новой системе входит в нормальное русло.

Для хорошо управлявшегося проекта и конструктивного взаимодействия в связке “Заказчик-Интегратор” пожарная содомия не превосходит масштабов бури в стакане, а возвращение работы компании в нормальное русло не длится долее недели.

IEM-система эксплуатируется в рабочем режиме? Время для денег.
В соответствии с моделью честного деления рисков Заказчик имеет право в течение месяца после запуска в эксплуатацию отказаться от внедренной системы. Без указания причин. И, соответственно, НЕ платить за нее.
Более того, Интегратор безусловно обязан возвратить все гарантийные авансы, полученные до этого.

Вероятно, именно благодаря такой схеме расчетов история внедрений IEM (пока) не знает ни одного провала.

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

Редчайшие же случаи удач внедрений ERP (а их, если честно, примерно раз в десять меньше, чем сообщается в пресс-релизах: "спираль молчания") относятся к тому классу ситуаций, когда НЕкастомизируемая модель бизнес-процессов, предзаложенная в ERP-систему, по счастливой случайности удовлетворительно совпала с реальностью вашей компании: “даже стоячие часы два раза в сутки показывают правильное время”.
Впрочем, когда речь идет о современном бизнесе на конкурентном рынке, такое совпадение невозможно даже теоретически.

6. Очень крупные внедрения

Случаи либо географически распространенных (подобно Walmart), либо функционально диверсифицированных предприятий (конгломераты типа GE).

В обоих вариантах деятельность компании очевидно раскладывается на совокупность полу- либо вовсе независимых бизнес-юнитов.
В такой постановке риски единовременной миграции всех бизнес-юнитов предприятия на IEM-платформу очевидно превышают выгоды, поэтому миграция выполняется для каждого бизнес-юнита поочередно (либо пакетно группами).
Бизнес-юниты, уже управляемые IEM-системой, ведут информационный обмен с отстающими частями общего предприятия как с внешними поставщиками/покупателями через информационные прокладки (web-сервисы, смарт-контракты, b2b-площадки, etc).

Постепенное присоединение остальных бизнес-юнитов к единой IEM-системе похоже поглощение черной дырой инфосферы Дайсона окружающей космической пыли и мусора: отдельные подразделения вливаются в единое информационное поле IEM и растворяются в монолитной единственности.

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

Заключение

“Правду говорить легко и приятно”.
Внедрение IEM-системы — это не только выгодно, это — фан.
Помните про неожиданные открытия на этапе преданализа? Иногда внедрение IEM-системы окупается еще до ее запуска.

В любом случае, после ввода IEM-системы в коммерческую эксплуатацию предприятие получает могучий фундамент для плавной эволюции в направлении кибернетического идеала IEM-компании.
Пусть недостижимому в полной мере, но однако любое продвижение на пути к нему будет стократно вознаграждено в графе “прибыль”.
Японцы называют это “кайдзен”.

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


Powered by Сон разума