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

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

 

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

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

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

М. Горький в предвидении 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-абстракции.

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

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

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

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

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

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

Почему «Технического» с большой?

Потому что это самый важный документ.

Он определяет project scopes — границы проекта — из чего, соответственно, вытекают и сроки, и деньги.

Содержание ТЗ на 100% определяет будущий функционал системы на момент завершения проекта внедрения.

Если там что-то не упомянуто, то, вне зависимости от как бы самоочевидных ощущений заказчика, это делаться не будет. Точнее, будет, но — сверх бюджета.

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

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.

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

October 02, 2014 by John Galt