Пробую разобраться с заданием курса Системного менеджмента: выводы из статьи «Physical foundations of biological complexity» применительно к выбору поставщика корпоративного софта.
Договариваемся "на берегу" о словаре: корпоративный софт - понятие обширное, но в данном контексте наибольший смысл вижу в обсуждении систем ERP класса.
Статья по ссылке выглядит ну очень кратким рефератом, выжимкой сотни других работ, поэтому невозможно было бы в посте еще раз пересказать ее - так же, как пытаться еще раз заархивировать файлы с архивами. Однако, чтобы собственное внимание в процессе написания текста, запишу основную мысль, как понял. Речь идет о самоорганизующейся критичности, свойстве систем лавинообразно увеличивать свою сложность, в то же время сохраняя в промежуточные периоды неустойчивый баланс между противоречивыми, тянущими в разные стороны векторами сил.
Перевод своих процессов на ERP или ее смена поставщика ERP для организации относится к такому возрастанию сложности, так как влечет за собой изменения в архитектуре предприятия.
Чтобы посмотреть, какие противоречивые силы действуют при замысливании и выборе такой системы, рассмотрю стремления различных ролей.
| Роль | Предпочтения | Развилки / tradeoffs |
| Закупщик | Автоматизировать сбор заявок на закуп ТМЦ, проведение конкурсов, контроль поставок и складские операции | Потеря гибкости и "договаривемости" в номенклатуре и условиях закупок |
| Операционный менеджер | Получить систему, поддерживающую ежедневное принятие решений | Увеличение когнитивной нагрузки: отчетов, планов, задач, "галочек" необходимых к ведению в новой системе |
| Инженер ИТ службы | Стремление уменьшить зоопарк систем, получить единую точку поддержки | Возможность срабатывания антипаттерна "Vendor King" |
| Вендор, поставщик корпоративного софта | Максимизация продаж - разовая и в виде подписочной модели | Сталкивание лбами нескольких вендоров, политические решения |
| Инженер целевой для организации системы | "Наращивание" системы до цифровой нити, интеграция с PLM. | Интеграция будет медленная и дорогая, но обязательная |
| Орг-архитектор | Избежать антипаттернов "Vendor King", “Ловушка последних 10%” | Стремление приобрести модульную систему с возможностью сопровождения и настройки в процессе эксплуатации |
| Финансист | Комплаенс, соблюдение требований внешних финансовых институтов и инвесторов и с внутренним управленческим учетом | Выбор требований / стандартов / их детализации |
| Бухгалтер | Совместимость с практиками ведения внутренного бухгалтеркого учета и с требованиями аудиторов | Приоритеты по совместимости с подпрактиками: кассовый учет, складской учет, кадровый учет, и т.п. |
| Подрядчики и поставщики | Четко прописанные "контракты", интерфейсы, правил по проведению конкурсов, заключению и ведению контрактов, своевременные платежи и документальные закрытия | Плохая совместимость, стыковка (не говорю про интеграцию) с корпоративным софтом и практиками самого подрядчика / поставщика |
| Директор, С-level | Управляемость, прозрачность деятельности Масштабируемость Модульность (в том числе для исполнителей ролей( Сохранить "медленные переменные" в организации |
Все перечисленные развилки других ролей, "взвешенные" по политическому весу и влиянию Принцип "Давайте прервем работу и назовем это успехом" |
| Собственник, инвестор | Улучшить финансовую привлекательность организации, "деньги сейчас" | Финансовые вложения |
Комментарии к таблице:
- Некоторые ментальные модели взяты из книги "Building Evolutionary Architectures", авторы Neal Ford, Rebecca Parsons & Patrick Kua. О книге писал в этом посте.
- "Vendor King" возникает, когда организация так увлекается ERP системой, что полностью выстраивает свою архитектуру вокруг этого продукта. В итоге появляется паталогическая привязка организации к инструменту. При покупке вендор обещает заказчику дополнить основной пакет функционалом подключаемых плагинов, чтобы подстроить функции программной системы под потребности бизнес-процессов. Однако, в большинстве случаев такую подстройку сделать не получается, и свежекупленный инструмент сковывает своими ограничениями всю архитектуру.
- “Ловушка последних 10%” возникает при внедрении системы на Low Code/No Code принципах. Поначалу развертывание идет как обещано: успешно, легко и быстро, совпадая с обещаниями маркетологов. Однако, на 80% функционала развертывание тормозит. Следующие 10% можно сделать только, обходя с помощью разработчиков ограничения фреймворка - например, с помощью скриптов. Так можно дойти до 90%. Последние 10% функций реализовать не удается вообще. Поэтому авторы книги называют ситуацию "ловушкой 10%".
- Принцип "Давайте прервем работу и назовем это успехом" (Let’s Stop Working and Call It a Success) - частая ситуация в реальном мире. Ни один директор не хочет признавать, что потратил впустую миллионы долларов, а поставщик инструмента - признавать неудачным многолетнее внедрение. Таким образом, каждая сторона соглашается прекратить работу и назвать систему успешной, при этом большая часть обещанных функций остается нереализованной.
- Про медленные переменные задумался после прочтения статьи "Жизнь как многоуровневое обучение" об идеях тех же самых авторов. Речь о том, что в развивающейся, обучающейся системе должны быть медленные переменные, не обнуляющиеся с каждым инкрементальным улучшением. Вспоминаю разговор с аккаунт-менеджером уважаемого, всемирно известного технологического вендора: он признался, что не располагает данными о выполненной 5-6 лет назад крупному заказчику поставке. Данные потребовались для проекта по модернизации уже устаревающей системы. Информация была потеряна потому, что вендор за пару лет до состоявшегося разговора перешел на новую ERP систему, и далеко не все данные мигрировали успешно. То есть вендор обнулил некоторую своих переменных при раскатываении корпоративного софта и, как минимум в кейсе с этим проектом, проиграл. Необходимую информацию о предыдущей поставке я нашел тогда у себя в архиве почтового ящика. Интересно, что про обнуление данных пишет и Steve Tendon в книге "The Book of TameFlow". Он критикует Scrum подход и вообще короткие итеративные циклы как раз за обнуление памяти.
Что в итоге? Думаю про системы успешные и гоню плохие мысли прочь. ERP поставлена, развернута, эксплуатируется, поддерживается.
- Уровень выше. Организация как целевая система: возрастает организационная сложность, со всеми своим плюсами. Новые характеристики: Отсутствие люфтов в управлении организацией, скорость изменения скорости в стратегии, модульность в орг.архитектуре, развиваемость/evolvability.
- Уровень ниже. Целевая система: Включена в цифровую нить: цифровая модель (а то и двойник) содержит синхронизируемые данные о физическом экземпляре системы. Данные помогают в течение всего срока эксплуатации целевой системы. За счет автоматизации, предиктивной компьютерной аналитики и прочих инструментов организации удается поддерживать важные характеристики системы, уменьшая стоимость эксплуатации, увеличивая безопасность, снижая риски и т.п.
Call it Success