Текст книги "Искусство бега по граблям. Стратегическое управление ИТ в условиях неопределенности"
Автор книги: Юрий Зеленков
Жанр:
Деловая литература
сообщить о нарушении
Текущая страница: 6 (всего у книги 8 страниц)
Очередь заданий с установленными приоритетами является входным буфером для команды поддержки и развития системы (отметим, что это аналог backlog в методе гибкой разработки scrum). Системный архитектор при необходимости связывается с автором заявки, уточняет возникшую проблему и формирует задание разработчику в терминах системы на «языке ИТ». Обновление, созданное разработчиком, тестируется архитектором и в случае успеха помещается в хранилище готовых объектов. Периодически (например, каждую ночь) система обновляется. Пользователь, сформировавший заявку, получает уведомление о ее реализации. Если он подтверждает, что его потребности удовлетворены, процесс прекращается, в противном случае он создает дополнение к ранее открытой заявке.
Это очень общая модель процесса инкрементального улучшения системы. В зависимости от условий конкретной организации она может быть дополнена различными элементами. Например, можно предусмотреть ежедневные короткие собрания всей команды развития для обмена информацией кто что делает, как это предписывает scrum. Также предложенная модель не отдает явное предпочтение тем или иным механизмам мотивации сотрудников, эти вопросы также должны решаться при внедрении процесса в конкретной организации.
Рассмотрим теперь процесс значительного изменения информационной системы при помощи выпуска релизов (рис. 6.9).
Данный процесс также строится вокруг приоретизированной очереди заявок на изменение или устранение дефектов, которая является входом для процесса инкрементальных изменений. Может сложиться такая ситуация, когда некое множество заявок целесообразно реализовывать одним пакетом, например, потому, что их взаимное влияние очень велико и независимая разработка невозможна. Подобная ситуация может сложиться также при обновлении технологической платформы, на которой построена система, при значительном добавлении новой функциональности и т.п. В этом случае представитель заказчика (напомним, что это владелец приложения или владелец процесса) и руководитель группы развития системы могут принять решение о выпуске новой версии (или релиза) системы. Они определяют границы релиза, т.е. множество заявок, которые он будет закрывать, и сроки его реализации. Отметим, что при планировании релиза крайне желательно оценить его потенциальный эффект и сложность реализации в соответствии с методом, предложенным в Главе 4.
Системные архитекторы в этом случае рассматривают релиз целиком и декомпозируют его на отдельные задания для разработчиков. По мере завершения разработки производится тестирование интеграции и функциональности вновь создаваемых модулей. Для этого целесообразно развернуть специальную тестовую среду, повторяющую окружение промышленной системы. К такому тестированию могут быть привлечены и ключевые пользователи. Когда внутреннее тестирование релиза завершается, он переносится в промышленную систему, о чем уведомляются пользователи, заявки которых реализованы в данном обновлении. Они также должны подтвердить удовлетворение их требований.
Отметим, что подготовка нового релиза выполняется параллельно с процессом инкрементальных изменений, причем одновременно в разработке может находиться несколько релизов, которые будут выпускаться последовательно.
Модель скользящих слоев
В этом разделе мы вернемся к обсуждению вопроса правильной организации технологической платформы, на которой может быть построена адаптивная информационная система.
Самый простой путь к обеспечению адаптивности не только информационной, но и любой другой системы, это разделение ее на относительно слабо связанные модули, которые могут развиваться независимо. Поэтому проблема проектирования и управления модульными системами с адаптивным поведением является центральной в исследованиях по теории организации. Однако, как заметили Сендил Этирадж и Дэниел Левинтол[121], при этом, собственно, вопросу оптимального выделения модулей уделяется мало внимания. Проектировщики сложных систем имеют дело с четырьмя видами решений:
1. разделение системы на «правильное» количество модулей;
2. «правильное» отображение параметров проектирования на модули;
3. «правильная» организация взаимодействия элементов внутри модуля;
4. «правильная» организация интерфейсов между модулями.
Общего решения этой задачи для систем любого вида, видимо, не существует. Тем не менее, в некоторых областях человеческой деятельности достигнут определенный успех в формализации разделения системы на модули. В частности, в строительстве и архитектуре существует концепция скользящих слоев (shearing layers), выдвинутая британским архитектором Фрэнком Даффи, основное внимание в своих работах уделяющим гибкому использованию рабочего пространства. Широкую известность этот подход получил после выхода книги Стюарта Бренда «Как обучается здание: что происходит после того, как оно построено»[122].
Согласно этой концепции здание рассматривается как комбинация нескольких слоев, которые существуют в различных масштабах времени, и обмен энергией, веществом и информацией между ними сведен к минимуму (таблица 6.4). Поэтому развитие таких слоев происходит автономно, без взаимодействия друг с другом. В быстрых слоях осуществляется поиск новых возможностей, медленные обеспечивают непрерывность, они служат инфраструктурой. Здание может адаптироваться к изменяющимся условиям, если обеспечено свободное «скольжение» слоев друг относительно друга, т.е. изменение быстрых слоев не затормаживается влиянием более медленных, и быстрые слои не деформируют медленные. Именно это обеспечивает максимальную адаптивность.
Возможность применить аналогичную модель для описания адаптивных свойств информационной системы выглядит очень привлекательно, поскольку практика подсказывает, что элементы ИС также имеют различные жизненные циклы. Наиболее общий пример – различие между моделью данных и собственно данными. Данные изменяются постоянно, в то время как модель остается относительно стабильной долгое время. Ключевая проблема при создании аналогичной модели для ИС – выделение слоев, изменяющихся в разном масштабе времени, и любой обмен между которыми минимален.
Су Линг Лим и Энтони Финкельшейн[123], рассматривая задачу управления требованиями при разработке программных систем, выделили четыре элемента, которые изменяются с относительно разными скоростями. В порядке перечисления от наиболее стабильных элементов к более изменчивым это:
Паттерны – элементы функциональности, которые остаются неизменными в течение значительного времени. Они инкапсулируют данные, базовые общие функции (такие, как add, find, get и т.д.) и основные функции, специфичные для конкретного домена данных, например, «зарезервировать» для паттерна «товар».
Функциональные ограничения, которые связаны с поддержкой выполнения пользователями их задач, и остаются неизменными, пока не меняются бизнес-процессы.
Нефункциональные ограничения, которые диктуются требованиями качества (например, время реакции, доступность и т.д.). Изменения этих ограничений не зависят от функциональности и возникают тогда, когда система перестает удовлетворять возрастающим требованиям по качеству, например, при увеличении числа пользователей.
Бизнес-правила, которые меняются наиболее часто, т.к. именно они обеспечивают реакцию организации на изменения во внешней среде. Например, менеджмент может решить сократить нормативное время обработки заказа от покупателя с 1 дня до 4 часов.
Такая классификация слоев, безусловно, имеет право на существование и представляет практическую ценность, но она применима только к программным системам. Если мы обсуждаем корпоративную информационную систему как единое целое, необходимо расширить рамки.
Корпоративная ИС может рассматриваться как набор проблемно-ориентированных подсистем (ERP, PDM и др.), которые работаю совместно и формируют единое целое. Каждая подсистема имеет связи с ресурсами и другими подсистемами, что приводит к сложному взаимодействию между ними. Можно выделить три сети, обеспечивающие связь между системами (рис. 6.10)[124]:
Физическая сеть связывает элементы оборудования и обеспечивает передачу данных между системными платформами.
Программная сеть предоставляет инструменты для трансформации передаваемых данных в информацию, которая совместно используется сотрудниками организации.
Социальная сеть обеспечивает взаимодействие людей, которые также являются компонентом корпоративной системы.
Это более традиционное представление корпоративной ИС, чем взгляд на нее как на комбинацию сервисов поддержки инфраструктуры, бизнес-приложений и бизнес-процессов, предложенный выше.
Изменения в любой сети, вызванные внешними причинами, должны сопровождаться соответствующими изменениями в других сетях. Поэтому каждая подсистема может рассматриваться как состоящая минимум из трех частей – техническое обеспечение, программное обеспечение и пользователи. Отметим, что это близко к традиционному представлению архитектуры предприятия в виде четырех доменов (бизнес-процессы, данные, приложения и техническая архитектура), но в данном случае домен данных и приложений объединен в один. К сожалению, такой таксономии недостаточно, поскольку она не позволяет выделить элементы с различными циклами изменения.
Развитием этого подхода в ИТ отрасли является широкое распространение виртуализации. В основном, это отделение слоя программного обеспечения от технического. Это позволяет несколько упростить процессы развертывания и миграции приложений, но на упрощение изменения самих приложений никак не влияет.
Также следует заметить, что в большинстве организаций подсистемы проектируются, реализуются и оптимизируются для решения относительно локальных проблем, очень редко присутствует единый взгляд на их сочетание, как корпоративную систему. Это объясняется тем, что не существует информационных систем, способных обеспечить все потребности достаточно крупной организации, приходится комбинировать продукты нескольких поставщиков. В результате подсистемы используют различные форматы и семантику данных, созданы с использованием разных языков программирования, реализуют несогласованные модели бизнес-процессов и требуют несовместимых программных платформ. Все это приводит к проблеме интеграции. Рональд Гьячетти и его коллеги[125] выделяют пять уровней интеграции:
на уровне организации (согласование целей);
на уровне процессов (координация);
на уровне приложений (интероперабельность);
на уровне данных (общее использование или data sharing);
на сетевом уровне (физическая совместимость аппаратных платформ и операционных систем).
Каждая подсистема имеет собственное множество пользователей, которое может пересекаться с множествами пользователей других подсистем. Изменения требований пользователей является одной из причин изменения подсистем, другая причина – это развитие технологий (см. уже цитировавшуюся книгу Б. Латура[126]). Однако возможность изменений подсистемы ограничена необходимостью взаимодействовать с другими подсистемами. В результате изменение, возникшее в одной подсистеме, может повлиять и на другие и даже на всю корпоративную систему.
Поскольку каждая система развивается в контексте корпоративной среды, мы можем провести аналогию между информационной подсистемой в организации и отдельным зданием, контекст для которого определяет город. Для того чтобы определить скользящие слои информационной системы, рассмотрим функции компонент здания и выделим соответствующие компоненты в ИС.
Оборудование (stuff) используют работники организации («пользователи здания») для выполнения своих повседневных задач и достижения операционных целей. Проблемно-ориентированная подсистема корпоративной ИС предоставляет для этой цели такие инструменты, как формы, используемые для создания и манипулирования информационными объектами, и отчеты для консолидации и анализа данных. Этому слою принадлежат также бизнес-правила и нефункциональные ограничения, которые выделены Су и Финкельштейном. Интеграционный механизм на этом уровне – согласование операционных целей, которые следует отличать от стратегических. Последние согласуются на уровне организации.
В слое планировки (space plan) создаются рабочие пространства, которые предназначены для совместного размещения организационных подразделений, рабочих групп, работников, выполняющих схожие операции, обеспечения им доступа к совместно используемой информации и изоляции их от других групп сотрудников и принадлежащих им информационных объектов. С одной стороны, рабочее пространство в корпоративной ИС создают персональные устройства (ПК, ноутбуки, планшеты и т.д.) с клиентским программным обеспечением, поддерживающим доступ к различным функциям при помощи меню, гиперссылок, панелей задач и т.п. С другой стороны, рабочее пространство связано с ролью пользователя, которая управляется системой контроля доступа. Функциональные ограничения, диктуемые необходимостью поддерживать выполнение пользователями их задач, должны рассматриваться на этом уровне. Интеграция здесь осуществляется на уровне координации процессов.
Слой сервисов (services) обеспечивает поддержку функционирования рабочих пространств (например, кондиционирование) и оборудования (например, телефонная сеть). Аналогиям в ИС являются элементы, формирующие ядро приложений: библиотеки, схемы данных, корневые объекты, паттерны в терминологии Су и Финкельштейна. На данном уровне интеграционные возможности не выделяем, они полностью определены функциями следующего слоя.
Наружная поверхность (skin) определяет, как здание вписывается в общий архитектурный облик города, и как оно использует элементы городской инфраструктуры. В случае ИС можно сказать, что этот слой отвечает за репрезентацию подсистемы с точки зрения других подсистем, другими словами, за ее интеграцию в общее целое. Эти функции обеспечиваются интероперабельными свойствами системы, включая интерфейсы, протоколы, возможности интеграции с корпоративным ПО промежуточного уровня. Интеграционный уровень здесь либо интероперабельность приложений, обеспечиваемая использованием таких механизмов, как MOM, ESB, SOA, либо простой экспорт–импорт данных.
Структура (structure) здания это фундамент, несущие стены и другие силовые элементы, которые невозможно заменить за время существования здания. Они соответствуют технической инфраструктуре, которая формирует фундамент ИС. Это может быть: центр данных и его инфраструктура, основные сервера, системы хранения данных, ядро сети, СУБД, программные платформы (такие как Java и .Net). Интеграция соответствует сетевому уровню.
В случае ИС сайт (site) – это организация, которая формирует контекст для всех корпоративных систем, включая информационные, управленческие, систему распространения знаний и т.д. Все эти рассуждения обобщены в таблице 6.5. [127] [128]
Предложенная модель скользящих слоев корпоративной ИС позволяет сделать несколько заключений о том, как ее подсистемы адаптируются к изменяющимся условиям. Изменения могут быть индуцированы бизнес-требованиями или новыми возможностями, которые предоставляет развитие технологий. Большинство новых идей появляется в наиболее изменчивых слоях – это «Оборудование» и «Планировка». Эти слои обеспечивают выполнение повседневных обязанностей, организуют размещение и предоставление доступа к соответствующим инструментам, формируют пространство для пользователей с одинаковыми функциями или в соответствии с бизнес-процессом. Именно за счет изменения этих слоев информационной системы осуществляется поиск и реализация новых возможностей. Однако надо заметить, что объекты слоя «Оборудование» (операционные цели, бизнес-правила, нефункциональные ограничения и, следовательно, формы и отчеты) меняются гораздо интенсивнее, чем объекты «Планировки» (процессы, функциональные ограничения, роли пользователей, рабочие пространства, персональные устройства). Это можно объяснить тем, что изменения первых вызываются в основном турбулентностью социальной составляющей организации. Эти изменения происходят ежедневно и непрерывно. Изменения вторых порождаются в большей степени появлением новых технологий. Основываясь на скорости появления новых персональных устройств, обновлении их операционных систем и соответствующих средств разработки, можно утверждать, что цикл изменений слоя «Планировка» составляет от 1 года до 3 лет.
Слои «Сервисы» и «Структура» значительно стабильнее, поскольку их изменения связаны с большими затратами, и технологии, которые являются основными драйверами изменений, также обновляются с меньшей интенсивностью. На основе истории развития инфраструктуры вычислений (мейнфрейм, мини-компьютер с терминалами, ПК в среде клиент-сервер, персональное устройство в облаке) можно сделать заключение, что средний период значительных изменений в слое «Структура» это 15 лет. Минорные изменения «Структуры» (такие как появление новых версий серверных операционных систем или систем управления базами данных) могут происходить чаще, каждые 3–5 лет. «Сервисы» также зависят от технологий (COBOL, 4GL и реляционные базы данных, программные платформы) и достаточно стационарных бизнес-требований, реализованных как библиотеки и фреймворки. Скорость их изменения составляет примерно 5 лет.
Изменения «наружной поверхности» ИС определяются развитием таких технологий, как Message-Oriented Middleware (MOM), Enterprise Service Bus (ESB), Service-Oriented Architecture (SOA), и происходят каждые 5–7 лет.
«Сайт», который представляет организацию в целом, может существовать десятки или даже сотни лет. Ее цикл изменений гораздо больше, чем цикл информационных систем.
В чем польза данного подхода к разделению ИС на модули? Вместо рассмотрения ИС по функциональным компонентам (СУБД, сервер приложений, подсистема безопасности и т.п.) мы выделили слои, сочетающие разный функционал, но изменяющиеся с одинаковой скоростью. Это позволяет уточнить требования к проектированию систем. Как было сказано, аксиоматическое проектирование допускает два вида матрицы проектирования – диагональный и треугольный. Мы теперь можем ужесточить это требование. Треугольная матрица проектирования, когда одно функциональное требование может влиять на несколько проектных решений, может быть допустима только при реализации всех этих требований внутри одного слоя. Связь требований с реализацией, которая осуществляется в разных слоях, должны описываться исключительно диагональной матрицей. Это обеспечит полную независимость требований и их реализации и, соответственно, независимость слоев.
Измерение уровня адаптивности ИС
Существенным вопросом является построение системы количественного измерения уровня адаптивности ИТ-инфраструктуры. Многие авторы отмечают, что данная задача чрезвычайно сложна, поскольку само определение адаптивности (обнаружение изменений и реакция на них) недостаточно формализовано. Более того, количественное измерение структурных параметров системы, определяющих ее адаптивность, невозможно, поэтому приходится ограничиваться измерением операционных характеристик. В связи с перечисленными проблемами наиболее широкое распространение получили подходы, предусматривающие качественную оценку[129], а также их развитие на основе лингвистических переменных и нечеткой логики[130].
Как уже было сказано, Р. Дав предложил для измерения операционных проявлений адаптивности использовать четыре количественных показателя[131]:
Время, требуемое для реакции на изменения;
Стоимость изменений;
Качество, понимаемое как устойчивость процесса изменений;
Объем изменений.
Частично этот подход реализован в банке Credit Suise Switzerland[132], где используется следующая метрика адаптивности ИС:
Здесь 
– осредненное время выполнения проектов по созданию новых систем, Ti – время выполнения i-го проекта (дни), si – размер i-го проекта, выражаемый в UCP (use case points); 
– осредненная стоимость проекта, Ci – затраты на выполнение i-го проекта. UCP это специальная мера функциональной сложности проекта, построенная на основе use case моделей языка UML[133]. Она предполагает выявление акторов и сценариев использования и оценку сложности на основе их весовых коэффициентов. Данная мера хорошо подходит для стандартных информационных бизнес-систем, где много пользовательского интерфейса и мало сложных алгоритмов. Альтернативами являются методика функциональных точек (functional point) и ее модификации. Таким образом, показатель, вычисляемый по приведенной формуле, представляет квадрат количества реализованной функциональности в UCP, отнесенный к произведению истраченных времени и затрат, что является комбинацией метрик времени, стоимости и объема, предложенных Р. Давом. В Credit Suise Switzerland показатель адаптивности, вычисляемый по этой формуле, в результате направленных действий вырос за 17 кварталов от 0,15 (июнь 2005) до 0,25 (сентябрь 2009). Интересно, что для проектов на базе собственной технологической платформы среднее значение показателя адаптивности за это время составило 0,24; для прочих проектов – 0,09.
В качестве критических замечаний можно высказать, что данная метрика, во-первых, оценивает только процесс разработки новой функциональности, во-вторых, не позволяет оценить качество изменений.
Более общую метрику, учитывающую также устойчивость процесса изменений, можно построить, исходя из следующих соображений. Модель изменений Лиитенена – Ньюмена, рассмотренная выше, предполагает две фазы изменений информационной системы – эволюционное развитие за счет инкрементальных изменений и революционную трансформацию в другое состояние. Мы определили, что именно адаптивные свойства системы позволяют ей эволюционировать, революционные изменения происходят, когда запас адаптивности исчерпан.
На основании результатов Дж. Хоббса и Р. Шиперса[134] можно предложить модель поддержания адаптивности ИС (рис. 6.11), которая предполагает формирование действий на основе непрерывного анализа текущих и предсказания потенциальных будущих потребностей. Отметим, что под внешней средой при этом понимаются все возможные системы, находящие вне периметра ИТ-департамента (другие подразделения организации, ее партнеры и конкуренты, разработчики и поставщики технологий, регулирующие органы и т.д.).
При этом деятельность ИТ-департамента по обеспечению адаптивности ИС на этапе ее эволюционного развития включает два процесса – разработка новой функциональности и поддержка системы. Оценить эффективность этих процессов можно с помощью энтропийной метрики, которая была предложена в пятой главе. Будем считать, что обнаружение потребности в изменении системы включает не только формирование заявки на изменение, но и согласование сроков ее выполнения. В случае запроса на поддержку эти сроки обычно регламентируются SLA, в случае разработки новой функциональности – устанавливаются путем переговоров в зависимости от объема изменения, его важности, доступного бюджета и т.д. (см. модели процессов инкрементального и революционного процессов изменения, рассмотренные выше). И в том и в другом случае назначенный срок является результатом соглашения между ИТ – департаментом и пользователями. Таким образом, в качестве характерного параметра процессов разработки и поддержки целесообразно определить отклонение фактического срока исполнения заявки от согласованного. Это дает возможность оценивать эффективность внесения изменений в ИС в целом.
Пример динамики изменения эффективности процессов разработки и поддержки приведен на рис. 6.12. Из рассмотрения данного графика можно сделать следующие выводы: в целом наблюдается положительная динамика по повышению качества, как разработки, так и поддержки, но процессы создания новой функциональности выполняются несколько хуже.
7. Институционализация
В нашем ремесле побеждают те, у кого есть приоритеты и нет принципов.
Карлос Луис Сафон. Игра ангела.
В заключение необходимо сказать несколько слов о том, как «узаконить» предложенные методы в организации.
Нашей жизнью управляют социальные институты – общественные правила, определяющие поведение некоторого подмножества членов того или иного сообщества[135]. В качестве такого подмножества можно рассматривать компанию, различные ее подразделения и даже ограниченный круг менеджеров высшего звена. Собственно сам процесс упорядочения, формализации и стандартизации социальных отношений и называется институционализацией. Очевидно, что какие-то системы ценностей, норм, идеалов, образцов деятельности должны регулировать и поведение относительно ИТ. Вопрос в том, может ли CIO повлиять на них? По моему мнению, не только может, но и должен. Если предложить своим коллегам – менеджерам других функциональных областей обоснованные модели (например, те, что предложены в этой книге) поведения и правила оценки результатов, самому строго соблюдать эти правила, велик шанс, что они и станут таким институтом. Далее обсуждаются некоторые принципы, которые могут помочь построить открытое и честное взаимодействие ИТ и бизнеса.
Роль CIO в компании, проблема выстраивания отношений с другими подразделениями и руководством – одна из тех тем, которые чаще всего обсуждаются профессиональным ИТ-сообществом. Часто CIO противопоставляется другим менеджерам. При этом выдвигаются такие аргументы: он ближе к неким сакральным технологиям, он единственный представляет все процессы и отвечает за их интеграцию и вообще он чуть ли ни единственный источник инноваций в компании. Очевидно, что такого противопоставления не должно быть, ИТ-подразделение всего лишь часть фирмы, не более (но и не менее!) важная, чем другие ее части. CIO должен быть полноправным членом команды менеджеров, участвовать в принятии решений, четко формулируя потенциальные возможности, ограничения и риски, возникающие в сфере его ответственности. Но тем не менее, проблема выстраивания диалога между ИТ и другими менеджерами часто существует, потенциальным способам ее преодоления посвящена эта глава.
У каждого человека существует набор приемов и утверждений, которые ему кажутся настолько наглядными и самоочевидными, что через них он объясняет все остальные факты и понятия. В науковедении эти базисные метафоры получили название «познавательные модели» (далее ПМ). В любой исторический момент в обществе обычно господствуют одна или две ПМ, формирующие научную парадигму в каждом разделе знания, а другие оппозиционны ей. Хотя каждая ПМ удобна для описания лишь какого-то круга явлений, на практике ведущая модель привлекается для объяснения всего на свете, и это часто делает познание односторонним, ущербным. Описание различных ПМ, которые окончательно оформились к настоящему времени, заимствованное из книги Ю.В. Чайковского[136], представлено в таблице 7.1. Отметим, однако, что уже угадываются контуры познавательных моделей, которые могут прийти им на смену.
Как уже было сказано, каждый человек принимает для себя одну из познавательных моделей (причем не обязательно господствующую в обществе на текущий момент) в качестве универсального средства «объяснения всего». Конечно, носители нулевой ПМ на руководящих должностях в современных компаниях встречаются крайне редко, но все прочие модели представлены весьма широко. А именно:
Маркетологи, специалисты по PR и журналисты в целом явно следуют семиотической модели – наблюдают факты и пытаются разгадать стоящий за ними смысл. Надо отметить, что первая ПМ вообще типична для начальных стадий научных дисциплин. Это попытка формализовать ранее не формализованную область знания.
Специалисты по производству, конструктора и технологи в большинстве своем привержены механической модели. Это следует из их профессиональной деятельности, где принцип причинности играет главную роль.
Экономисты одновременно используют и механическую, и статистическую модели. С одной стороны, в своих выводах они оперируют данными, которые часто невозможно прямо отнести к той или иной статье учета, поэтому они распределяются на основании других данных (базы). Да и сами экономические показатели при вычислении осредняются как по времени, так и по организации в целом. С другой стороны, все их рассуждения строятся исходя из предположения о существовании причинно-следственной связи затраты – доход (убытки).
Cпециалисты по качеству используют статистическую модель, опираясь на наблюдение динамики осредненных результатов процессов.
Топ-менеджеры и руководители компаний должны опираться, как минимум, на системную модель, иначе невозможно управлять такой сложной социотехнической системой, какой является современная компания.
Подчеркну, что данная классификация не имеет целью показать, что носители одной ПМ чем-то лучше или хуже других. Как было отмечено, каждая из них подходит для описания лишь ограниченного круга явлений. Группировка профессионального сообщества вокруг конкретного класса явлений формирует определенные институциональные правила, которые и вынуждают членов сообщества принимать соответствующую ПМ. Следствием этого являются трудности перехода от одной профессиональной роли внутри компании к другой. Например, если рядовой экономист становится топ-менеджером – директором по экономике, он должен отказаться от привычной механико-статистической модели. Иначе неизбежен конфликт, например, с директором по производству, который, в свою очередь, не отказался от механической модели. Как видим, такие конфликты, которые мы все неоднократно наблюдали в реальной жизни, являются скорее мировоззренческими, причины их не в ограниченности конкретных участников.
Какую же познавательную модель предпочитают специалисты по ИТ? Безусловно, это механическая модель. Профессиональная обязанность взаимодействовать с технологией, которая ориентирована на бинарную логику, поддерживает убежденность в причинности окружающего мира. Отсюда уверенность в существовании простых решений типа «внедрим ERP и будет сразу все хорошо», требование финализированного ТЗ перед началом разработки системы и т.д. CIO, выросший из технического специалиста, как и любой другой руководитель верхнего уровня, должен поменять познавательную модель на системную, иначе он просто не задержится на новой должности. Все мы знаем настоящих CIO, которые мыслят в терминах системной ПМ, и «начальников АСУ», которые так и остались верны прежним представлениям.
Все предложенные в данной книге модели и методы построены в рамках системной ПМ. Поэтому продвижение их среди менеджмента компании в качестве институциональных правил может натолкнуться на простое непонимание со стороны «пользователей» других моделей. Очень важно выделить этих последователей, переформулировать предлагаемые принципы в соответствии с их картиной мира (или, что гораздо сложнее, попытаться изменить их картину мира), иначе такое непонимание станет потенциальным источником конфликта.
