В данной под авторизмом я понимаю явление, при котором управление в первую очередь опирается на личный опыт, знания и умения руководителя, при этом обратная связь от подчинённых имеет вторичный характер. Природа авторитаризма занимательна и требует отдельного рассуждения, здесь же я попытаюсь показать, как нивелировать основные недостатки авторитарного подхода в управлении и усилить его достоинства. ИТ очень чувствителен к ошибкам управления: авторитаризм может быть разрушителен, а может и вознести предприятие до небес (Стив Джобс был авторитарен).
Авторитарный подход и наоборот
Есть два подхода к управлению: авторитарный и наоборот. Наоборот—это подход, основанный на совместном создании ценности. Оба подхода имеют плюсы и минусы. Авторитарный подход опирается на личность (система вторична), результат достигается быстрей и очевидней эффект (который, впрочем, часто имеет краткосрочный характер), но крайне высок риск провала. Второй подход опирается на потребности системы, он надёжней и менее рискованный, результат получается основательный и стратегический, но более долгий, увы. И, к сожалению, здесь риск провала так же вероятен, но провал будет иметь стратегический характер.
Авторитарное внедрение сайта «Cover Oregon» (США) обошлось в $248 млн. и было провальным. Сайт «Cover Oregon» должен был автоматизировать предоставление услуг частного медицинского страхования; он должен был обеспечивать участие в государственной программе страхования Medicaid и других программах государственной помощи. Сайт «Cover Oregon» должен был выступать в качестве единого окна для медицинского в штате Оригон. Доложен был, но. Когда в октябре 2013 года сайт запустили, пользователи не могли даже зарегистрироваться в нём. В ноябре 2013 года штат Орегон нанял сотни сотрудников, которые для оформления страховок с помощью старых добрых ручек с бумажками. Проект закрыли: на его доработку требовалось дополнительные $78 млн., а переход на централизованный аналог стоил $4–5 млн. Провели несколько расследований. Выяснилось, что руководители, проекта, не отслеживали реализацию проекта а просто показывали оптимистичные отчёты, за которыми скрывались существенные проблемы. С моей точки зрения, авторитарное управление почти всегда иллюзорно. При авторитарном подходе управление опирается на личный опыт, знания и чутьё первого лица. Обычно, при таком подходе, хорошо развита отчётность. Данный пример‑это повод учитывать и понимать риски авторитарного управления.
Альтернативное управление, опирающееся на принципы совместного создания ценности (требования стейкхолдеров и договорённости) так же не лишено недостатков: критичен риск того, что основная цель управления (линия партии) станет вторичной. Множество раз сталкивался с диктатурой стейкхолдеров, которые саботировали или делали невыгодным достижение той или иной цели.
Однажды в Британской Колумбии решили создать парк высокоскоростных паромов‑молодцы! Местные производители алюминия получили заказы, местные верфи тоже получили заказы, были созданы рабочие места для строительства паромов из местного алюминия, политики получили поддержку населения. За $460 млн. канадских долларов было построено три парома, которые всего через несколько лет продали всего за $19 млн. канадских долларов, как металлолом, несмотря на то, что были покупатели, готовые заплатить и $60, и $88 млн. канадских долларов. Паромы по многим причинам не стали скоростными. Расследование показало, что при строительстве паромов во главу угла ставились политические задачи развития местной экономики и социальной инфраструктуры‑руководители проектов не проигнорировали то, что местные верфи не умели строить паромы. В ходе расследования выяснилось, что строительство паромов у сторонних подрядчиков было значительно дешевле. В управлении нельзя идти на поводу у заинтересованных лиц.
Процессный подход в управлении, как способ решения противоречий авторитарного управления
Слабость авторитарного подхода в управлении — это то, что руководитель, часто управляет «на ощупь». Отчёты врут, подчинённые скрывают. А демократию, при которой цель предприятия становится менее важной, чем цели подчинённых, руководитель уже наелся. Поможем, авторитарному руководителю, тем более, что учёные давно всё придумали.
Оперативность‑это основное преимущество авторитарного управления, которое может сойти «на нет» вследствие несогласованности управления, противоречий горизонтального взаимодействия и противоречия вертикальных коммуникаций. Процессный подход снимает множество недостатков управления. Рассмотрим ITIL‑процесс «Управление проблемами ИТ». Его цель‑предотвращение и минимизация влияния инцидентов на ИТ‑услуги. Мы увидим, как грамотно выстроенный процесс может снять часть противоречий, но сначала я опишу контекст рассуждений.
Информационный ресурс (инженерная система, автоматизированная система) имеет следующий жизненный цикл: Создание (Идея, Выделение ресурсов, Проектирование, Разработка, Ввод в эксплуатацию), Эксплуатация (Подготовка требований к эксплуатации, Создание инструментов эксплуатации, Операционная деятельность, Аналитика), Утилизация (Осмысление/рефлексия/валидация, Обсуждение/коммуникации, Улучшение, Верификация/утверждение результатов).
Обычно за этап Создание — отвечает организация поставщик(вендор, разработчик и т. п.), а за эксплуатацию информационной системы отвечают другие.
В больших организациях, с информационными системами, работающими в режиме 24×7 за их работоспособностью следит сменный администратор, который и устраняет большинство инцидентов.
Менеджер проблемы — это руководитель (начальник отдела, например), который берёт на себя решение организационной составляющей проблемы.
Будем размышлять в данной парадигме.
Противоречия процедур управления
Несогласованность процедур управления — это когда одна рука делает то, о чём не знает другая. Рассмотрим типичный сценарий решения проблемы, диагностированной на этапе Создание.
Частный сценарий решения проблемы, Админу будет хорошо, если при внедрении информационной системы или её версии разработчик предупредил его о возможной проблематике, способах её обхода. Админу нужен верхний левый угол схемы. При авторитарном управлении, обычно выстраивается система контроля качества(правый нижний угол), при которой плохое ПО ведёт к санкциям и разработчику будет плохо, если он признается в том, что его система имеет проблемы.
При таком подходе разработчикам не очень хочется говорить о проблемах, которые, могут привести к сбоям, а могут и не привести. Получается, что админ хочет знать заранее, а разработчик хочет скрыть — противоречие.
В авторитарных экономических системах, когда ошибка стоит дорого, нарисованная схема часто не работает или работает формально. Поставщик делает вид, что разработанная им система идеальна, клепает великолепные отчёты с презентациями, подписываются акты приёмки, «великолепная» система внедряется, но под плач администраторов.
Руководители, которые не знают о недостатках системы (которые нигде не зафиксированы), управляют «вслепую» и переплачивает. Сталкивался с любопытным явлением, когда разработчики и админы из разных организаций договаривались о совместной починке информационной системы за спиной начальства, считающего, что информационная система не имеет проблем.
Процесс — это свод правил, которые принимаются всеми. Принимая и понимая проблематику несогласованности управления, нам нужно так организовать работу в правом нижнем углу схемы, чтобы она не мешала проактивной фиксации проблем на стадии Создания информационного ресурса, в левом верхнем углу схемы. Хорошо построенный процесс снимает противоречия между различными процедурами системы управления. Иными словами: утилизация проекта внедрения информационной системы не должна мешать проактивному решению проблем. Поэтому контракты, SLA и OLA, должны заключаться максимально честно, без вранья и иллюзорных ожиданий, свойственных авторитаризму.
Даже не авторитарные экономические системы имеют авторитарные элементы управления. Многие предприятия живут в двух реальностях: отчётной и проблемной. Одна из ключевых задач менеджмента процесса «Управление проблемами» — это приведение отчётной реальности к «реальной». Потихоньку, шаг за шагом, можно приучить руководителей говорить проблемах и ходе их решения, минимизируя иллюзии.
Задача обеспечения реалистичности отчётности ставится обычно первым лицом предприятия, которое не хочет управлять «вслепую». Процесс «Управление проблемами» часто называют «директорским» по этой причине. Организационные вопросы утилизации обычно решаются на коммуникационных площадках в формате «стратегических сессий». Это дело не одного и не двух совещаний.
Противоречия горизонтального взаимодействия.
Рассмотрим схему решения проблемы, возникшей на этапе эксплуатации информационной системы. Пусть, для большей определённости, проблема связана с плохим качеством программного обеспечения. Ниже представлена условная схема решения этой проблемы.
Каждый прямоугольник из схемы — потенциальный источник противоречий взаимодействия: разработчик не всегда оперативно разрабатывает обходные решения(админу приходится выкручиваться с помощью настроек серверов), админ не всегда предоставляет полную информацию о состоянии системы, не всегда следует рекомендациям разработчика... Мне, как разработчику в прошлом, админы были долго непонятны. Они считали меня поверхностным и ненадёжным, я считал их скучными и некреативными‑оба мнения ошибочны. Первые кросс‑функциональные диаграммы, подобные той, что выше, я начал рисовать, чтобы найти общий язык садминами. Им очень нравятся квадратики со стрелочками . Обычно каждый квадратик процесса обвешан метрикой или даже показателем. Нет более крепкой вражды, чем вражда из‑за показателей. При авторитарных подходах в управлении, такие конфликты скрываются даже от линейных руководителей, тем более о них не знает директор. Задача процесса‑это обеспечение согласованности действий участников процесса. Перед игрой в «дурака» уточняются правила. Для снижения конфликтов и повышения взаимопонимания между участниками, при построении процесса, рекомендуется проведение коммуникационных площадок по построению процедур процесса.
И. Внимание! С помощью коммуникационных площадок можно определять механизмы определения и контроля целевых и плановых значений показателей. Но такие трюки, конечно же, являются искусством управления. Проще ставить целевые значения показателей «на глазок», авторитарно. В прошлой статье я приводил пример английских больниц, когда автомобили скорой помощи с больными внутри простаивали на улицах ради соблюдения показателя время ожидания в очереди. В этом абзаце я хвастаюсь. Эх!
Противоречия вертикальных коммуникаций
Boeing 737 MAX — имел проблематику с системой стабилизации полётов MCAS, про это говорили много лет и профсоюзы пилотов и инженеры, но понадобилось две авиакатастрофы и 346 погибших, чтобы услышать эти обращения. (ссылка)
Как программный продукт, MCAS имела следующую типичную для информационных систем проблематику проектирования и низкого качества ПО:
Система считывала информацию, только с одного датчика. При выходе датчика из строя, план Б отсутствовал. (В 2019 году, CNN сообщила, что с 2004 года FAA получило по меньшей мере 216 сообщений о выходе из строя датчиков AOA или необходимости ремонта, замены или регулировки ) Применённые решения проблем несли риски и изменяли типовой процесс управления авиосудном.
Изначально система разрабатывалась для работы на высоких скоростях, тогда, как стабилизация была необходима и на низких скоростях. При расширении функционала были внедрены опасные «костыли».
Типичная проблематика проектирования сопровождалась типичной организационной проблематикой:
Решение проблем проектирования и низкого качества ПО осуществлялось реактивно, после возникновения инцидентов, стоимость некоторых из них измерялась человеческими жизнями.
Проблемы MCAS и вытекающие риски были известны, однако руководители компании Boeing игнорировали проблематику.
Авиакомпании, то есть заказчики/клиенты, не были проинформированы о проблематике и рисках MCAS. Зачастую, клиенты не информировались о найденных «обходных решениях»
Мы видим пример плохих вертикальных коммуникаций, замалчивание проблемы и катастрофы, в итоге. Использование Boeing 737 MAX было приостановлено на годы. Были миллиардные убытки.
Сложность вертикальных коммуникаций чаще всего связана со сложностями эскалации той или иной проблематики. Схематично эскалация выглядит довольно просто.
В схеме предусмотрен, как процессный, алгоритмизированный подход, так и ручное управление. В жизни взаимодействие с внешним миром часто происходит в ручном режиме, хотя бы потому, что окружающим «плевать» на ваши внутренние процессы. Управление мощностями, поставщиками и обычно хороши пока они внутри. Ручной режим имеет свои нюансы.
Чем выше должность, тем сложней решать вопросы, с которыми не справились твои подчинённые. Не каждый руководитель найдёт в себе мужество признать, что система, принятая в эксплуатацию «без замечаний» никуда не годится. Не каждый руководитель ухитрится выбить лишние миллионы на необходимые мощности. Очень страшно признавать, что впечатляющие успехи проекта имеют сугубо отчётный характер, а реальность кричит о провале.
Эскалация — самая сложная процедура процесса: легко решить проблему PostgreSQL с помощью Huge Pages, много сложнее найти деньги на перепроектирование неоптимальной модели приложения, создающего неприемлемую нагрузку на сервер БД.
Ручной режим эскалации с виду прост: посовещался, понял, что решить не можешь, эскалировал проблему «вверх». Верх посмотрел, посовещался, понял, что не может, эскалировал проблему ещё выше. В итоге формируется куча не решаемых проблем. «И Чо?» — спросит вас директор. Наука и интернет не щедры в описаниях механизмов эскалации проблем — это серая зона практик.
Организационный «trouble shooting» — не алгоритмизированная область управления. Решения таких проблем могут лежать в области управляемых коммуникаций: стратегических сессий, коммуникационных площадок в виде игр, мозговых штурмов и банальных совещаний.
Основные процедуры и противоречия процесса «Управления проблемами»
Конфигурация процесса управления проблемами очень сильно зависит от организационной структуры ИТ-предприятия и зрелости его системы управления. Перечислю основные возможные процедуры процесса и противоречия, которые их сопровождают.
Выявление и регистрация Проблемы. Основное противоречие в сокрытии проблем.
Анализ проблемы. Противоречия обмена диагностической информацией между различными участниками процесса (разработка, сервера, сеть, смежные системы).
Поиск корневой причины Проблемы. Противоречия определения зоны корневой причины, доказательства её наличия.
Поиск обходного решения. Противоречия взаимодействия, рассматривали выше.
Поиск постоянного решения Проблемы. Коммуникативные противоречия админ‑разработчик.
Реализация постоянного решения Проблемы. Противоречия взаимодействия админ‑разработчик.
Контроль известных ошибок.
Приостановка работ по Проблеме. Если проблема не решается по объективным причинам, к примеру, разработчик обанкротился, её можно приостанавливать, если известно обходное решение. Множество разнообразных противоречий.
Эскалация Проблемы на уровень Руководителя среднего звена, рассматривали выше.
Эскалация Проблемы на уровень Руководителя высшего звена, рассматривали выше.
Эскалация Проблемы на поставщика. Противоречия управления контрактами.
Закрытие Проблемы. Противоречие критериев качества решения проблемы. К примеру, пусть у нас вечно некачественное ПО и плохое тестирование. Решение десяти проблем с недоступностью различных страниц‑это решение десяти частных проблем. Но остаются не решенными проблемы тестирования и организации разработки.
Коммуникации, как способ решения проблем
«Я — уборщица. Не бойся меня. Говори смело и понятно, потому, что я глупая уборщица. Нет! Уборщица — уважаемая профессия! Я — ребёнок от семи до четырнадцати лет. Объясняй мне просто, как ребёнку. И не бойся!», — ровно так я говорил с одним программистом, который панически боялся говорить, а если говорил, то бессвязную ерунду, несмотря на недюжинный ум. Не только лишь все умеют общаться.
Один из смыслов данной статьи заключается в том, коммуникации важны. Менеджмент процесса должен обеспечивать коммуникации между участниками на протяжении всей жизни проблемы. При управлении процессом нужно уметь «видеть» участки процесса, на которых возникают проблемы общения: враждующие подразделения, часто официально дружелюбны; руководители часто не могут снизойти до общения с простым исполнителем; простой исполнитель может быть социопатом….
Данная тема требует отдельных размышлений, здесь лишь хочу сказать, что от качества коммуникаций зависит развитие процесса снизу. Управление коммуникациями, как это ни странно, требует максимально авторитарных подходов, дабы не превратить мозговой штурм в базар и бенефисы «неформальных» лидеров. Перед любых проведением коммуникаций (обмен опытом, стратегические сессии, мозговые штурмы, игры и т. п.) необходимо проведение тщательного анализа и работа с большими данными, для выявления и трассировки отклонений. На коммуникациях сотрудники получают обсчитанное и чётко описанное противоречие и затем, ищется более — менее точное решение.
Что получим после внедрения процесса «Управление проблемами»?
Резюмирующий раздел статьи.
Руководитель первого уровня получит:
Измеримую информацию о качестве ИТ ‑инфраструктуры в терминах сбоев(причины, длительность, частота)
Измеримую информацию о степени готовности ИТ к возможным сбоям
Приоретизированные потребности в обновлении мощностей
Измеримую информацию о ходе реализации изменений, направленных на решение проблем
Измеримую информацию о качестве предоставления «проблемных» ИТ‑услуг
Снижение проблем взаимодействия между сотрудниками на операционном уровне
Повышение оперативности и качества решения проблем, то есть снижение влияния сбоев на автоматизируемые бизнес‑процессы
Процессный подход минимизирует влияние человеческого фактора и влияние самодуров‑руководителей в управлении и, одновременно, усиливает авторитарный подход первых лиц. В этом заключается противоречивое его очарование.
Применение инструментов процессного подхода в управлении — это дорого. Если не уметь или пустить всё на самотёк, то дороговизна станет невероятной. Поэтому, при внедрении и эксплуатации процессов, нужно регулярно задавать простой вопрос: а какие противоречия снимет тот или иной процесс. Нужно проводить аудит и анализ, для выявления противоречий, существующих на предприятии. И, уже отталкиваясь от выявленной организационной проблематики, разрабатывать и внедрять процессный инструментарий.
Забавная история про противоречия вертикальных коммуникаций, для настроения:
Король Швеции Густав II Адольф построил один из самых грандиозных и дорогостоящих кораблей и назвал его Ваза(Vasа). Летом 1628 года произошел первый рейс флагманского корабля: он вышел из гавани, проплыл меньше мили и потонул: центр тяжести был слишком высок из‑за обилия пушек и украшений. Погибло, по разным источникам, от 50 до 400 человек.
Между тем, перед рейсом проводились испытания, проблемы с устойчивостью выявились, но все промолчали. Промолчал и Адмирал, ответственный за построение корабля, который прервал испытания корабля, поняв, что корабль может перевернуться прямо в порту. Перед первым рейсом корабль просто хорошенько загрузили.
После того, как Ваза потонула, провели расследование, в ходе которого выяснили, что никто не виноват. Потому, что техдокументацию на корабль подписал сам Король Швеции Густав II Адольф.