Методология внедрения IEM System. Стратегия цифровой трансформации

 
Статьи
Методология внедрения IEM System. Стратегия цифровой трансформации

Принципы развертывания IEM System абсолютно противоположны ERP-методологиям.

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

Помните про Profitability Extremum IEM Предприятия? Иногда внедрение окупается еще до запуска.

«CEO создан для счастья, как птица для полета»

М. Горький в предвидении IEM

Методология развертывания 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 предписывает работу только с подготовленными заказчиками, и прямо запрещает т.н. «активные продажи».

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

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

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

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

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

В частности, получить общее, но адекватное представление про:

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

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

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

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

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

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

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

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

В параллели с проектным институтом, предполагаемым генеральным проектировщиком будущего строительства, — здесь мы выясняем, что

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

Ну и еще миллион менее важных моментов, не будем перегружать.

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

Нет ничего легче.

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

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

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

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

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

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

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

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

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

Если же существенные расхождения зафиксированы, то отношения естественным образом завершаются. Аналогия с врачом и пациентом: если пациент не согласен с диагнозом, как может идти речь о результативном лечении? Обратитесь к другому специалисту.

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

Пациент просит врача:

— Христа ради допишите в рецепт настоечку спиртосодержащую, пожалуйста, ну чего вам стоит. Жена сильно против, а тут для здоровья от врача, не поспоришь!

— Ладно, больной, вот вам еще три пузырька тут допишу, но только вы не слишком там злоупотребляйте!

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

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

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

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

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

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

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

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

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

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

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

Процессное задание не содержит любимого повода для многочасового сцепления языками: описания экранных форм, где какие галочки и какого цвета кнопочки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обобщение опыта внедрений IEM показывает, что главным риском проекта на этапе разработки кибернетической модели является затягивание сроков из-за фокусировки внимания как раз на «отделке»: эстетике и удобстве интерфейсов, необязательном для запуска наращивании детализации модели, и так далее. 

Эта деятельность может продолжаться бесконечно («ремонт нельзя закончить, его можно только остановить»). Ведь бизнес эволюционирует непрерывно, в системе всегда есть что доделать и улучшить.

Но — никакого практического смысла в этих улучшениях нет: бизнес не может ими воспользоваться, пока не работает в IEM Системе.

Более того, в процессе имплементации свежих эстетических идей устаревают элементы эстетики, реализованные ранее. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

Для масштабных слабосвязных конгломератов (например, General Electric) и крупных непрофильных бизнес-направлений (например, производство private label для сетевого ритейлера) объединение всех операций в рамках одной IEM Системы, как правило, практического смысла не имеет.

Для каждого независимого дивизиона рекомендована локальная инсталляция IEM System, а взаимодействие между ними организовывается в логике локального сгустка Internet of Enterprises, сохраняя при этом все операционные преимущества IEM Paradigm.
 

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

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

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

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

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

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

October 02, 2014