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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ФЗ — видение, описывающее функционирование предприятия to be (на момент перехода) в IEM-абстракции.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В соответствии с логикой 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