Методология развертывания IEM System естественным образом вытекает из ее философии и архитектуры, и столь же естественно противоложна практикам внедрения ERP.

Если само словосочетание «внедрение ERP» у ИТ-профессионалов вызывает характерные ассоциации в духе «машинное масло с металлической стружкой навсегда», то переход бизнеса под управление IEM-системой — нечто диаметрально противоположное.

Если методология внедрений ERP — ярко выраженный waterfall, то IEM — квинтэссенция agile.

Если для внедрения ERP-системы скрупулёзно проработанное и максимально детализированное техническое задание — условие sine qua non, чтобы получить хоть что-то рабочее, то для эффективного развертывания IEM System достаточно видения бизнеса в состоянии to be в абстракции цепочек создания стоимости.

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

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

Именно поэтому как заказчикам, так и интеграторам IEM System, надлежит забыть навыки и подходы, наработанные в работе с ERP.

Понимание сути IEM-методологии, и ее тотальной противоположности best practices ERP-проектов, необходимо, чтобы максимально монетизировать преимущества IEM.

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

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

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

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

— техническую. Трансляция «портрета» в пространство бизнес-логики IEM

Креативная компонента реализуется в плотном сотрудничестве Интегратора и менеджмента Заказчика.

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

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

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

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

Вы связываетесь с интегратором IEM Системы.

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

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

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

Интегратор: слушает, задает уточняющие наводящие вопросы. Мало рассказывает, и совсем ничего не показывает.

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

Если риск проекта, с учетом всех выявленных аргументов «против», признан Интегратором приемлемым, то предприятие Заказчика, соответственно, — пригодным для развертывания IEM Системы.

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

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

Иными словами, как будет выглядеть и работать ваш бизнес на момент запуска IEM Системы.

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

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

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

Это все очень важно, но — не главное, а детали.

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

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

Если же существенные расхождения зафиксированы, то отношения естественным образом завершаются.

Если Заказчик настаивает на включении в минимальную модель неких артефактов, не сильно влияющих на успешность проекта в целом, то Интегратор (как правило) идет навстречу пожеланиям Заказчика.

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

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

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

2. Написание и утверждение Процессного задания

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

А именно — формализация и согласование Процессного задания (ПЗ).

В ПЗ формально описывается конфигурация минимальной модели предприятия в IEM-абстракции. А именно:

— перечень основных цепочек создания стоимости (бизнес-процессов) предприятия, и их деление на этапы

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

— основные роли (категории) пользователей

— глобальный функционал (веб-сайты, b2b-порталы, мобильные приложения, подключение к внешним ИТ-системам — ЕГАИС, Меркурий, СКУД, маркетплейсы...)

Иными словами, в ПЗ описывается, что управляющая система предприятия будет делать (а не как).

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

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

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

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

Наиболее эффективная стратегия минимизации затрат на миграцию — минимизация продолжительности транзита.

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

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

Заказчик согласен? Поехали.

Схема честного деления рисков запрещает интегратору IEM брать деньги вперед более 50% стоимости проекта.

В соответствии с ней же, Заказчику рекомендуется выплата аванса (не более 50% стоимости) как гарантии серьезности намерений и мотивированности будущих усилий.

4. Разработка кибернетической модели компании

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

Трудоемко, но в целом тривиально.

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

В который раз обращаем внимание:

— работоспособными, а не идеально оптимизированными.

— основные цепочки создания стоимости, а не все бизнес-процессы компании вообще.

В соответствии с логикой agile-разработки (a continuous delivery — базовая техника прикладной разработки для IEM System), мы въезжаем в построенный дом с подключенными коммуникациями, но с не завершенной до конца внутренней отделкой.

Отделка доводится «на лету» на следующих этапах.

Именно поэтому — воля, энергия и административный ресурс команды проекта должны быть сфокусированы на максимально быстрый запуск IEM Системы.

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

Более того, только лишь реальный перевод бизнеса под управление IEM Системы и покажет, какие именно «отделочные работы» действительно необходимы в первую очередь.

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

Как только наш кибер-авианосец может самостоятельно передвигаться, — немедленный «спуск на воду», и доводка на ходу.

Готовность к переходу — акт воли.

5. Запуск в эксплуатацию. Недели стресса в компании

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

Момент истины для команды проекта. Начало отсчета длительности периода try & buy.

В соответствии с моделью честного деления рисков Заказчик имеет право в течение периода try & buy (то есть, после запуска в эксплуатацию) отказаться от внедренной системы. Без указания причин.

В этом случае Интегратор возвращает Заказчику половину стоимости работ.

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

6. Полировка модели

На предыдущем этапе мы добились устойчивой работы основных бизнес-процессов компании в IEM Системе.

Время позаботиться об удобстве пользователей.

Помимо сугубо интерфейсной оптимизации, тут исправляются неоптимально реализованные фрагменты модели (видение to be естественным образом эволюционирует в процессе разработки и перехода).

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

Общая длительность этапа — порядка трети от этапа разработки.

На этом проект внедрения как таковой завершается: цифровой двойник в IEM Системе оптимально отражает реальный бизнес.

Далее — эксплуатация.

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

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

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

В обоих вариантах деятельность компании очевидно раскладывается на совокупность полу- либо вовсе независимых бизнес-юнитов.

В такой постановке риски единовременной миграции всех бизнес-юнитов предприятия в периметр IEM Системы очевидно неприемлемы, поэтому миграция выполняется для каждого бизнес-юнита поочередно (либо пакетно группами).

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

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

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

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

8. Заключение

«Правду говорить легко и приятно».

Внедрение IEM Системы — это не только выгодно, это еще и фан.

Помните про Profitability Extremum IEM Предприятия? Зачастую внедрение IEM Системы окупается еще до ее запуска.

В любом случае, вводом IEM Системы в коммерческую эксплуатацию бизнес получает могучий импульс плавной эволюции в направлении кибернетического идеала IEM Enterprise.

Пусть недостижимому в полной мере, однако любое продвижение на пути к нему будет стократно вознаграждено в графе «прибыль».