Архитектура большей части больших организаций схожи: они имеют типовую структуру с набором типичных процессов. Большая организация работает размеренно, однообразно, неторопливо. Неспешно ставятся и достигаются цели, устраняются катастрофы и их причины. Существует множество способов улучшения организационной архитектуры. По идее если устранить трансакционные проблемы, то можно разрабатывать доступные типовые решения по улучшению организационной архитектуры.
Описывать в блоге процессы управления из практик и гостов? Сбои/инциденты, проблемы, риски, проекты, коммуникации… Почему бы и да?
Начну с процесса Управления проблемами. Это порядка пятнадцати- двадцати блогов.
И ещё: умение решать проблемы—это один из способов сделать карьеру честным образом. Про это в каждом блоге.
Здесь ТС мне напоминает пьяного Дон Кихота, который обещает победить все мельницы на районе.
Хотя... Эта информация продается консалтинговыми фирмами за дикие деньги.
* * * * * * * *
История про то, как Боинг забил на проблему.
Боинги 737 MAX —это публичный стыд американского авиастроения. Недавно у одного из них в полёте вылетела дверь. А в 2009 году один из них упал под Амстердамом—погибло 9 человек. Потом они падали в Индонезии и в Эфиопии—погибло 346 человек.
Самолёты падали потому, что:
Плохо срабатывал механизм балансировки, который не позволяет самолёту уйти в пике.
В 737 Max нет датчика, который оповещал бы пилотов о неверных данных с сенсора угла атаки самолёта.
Автопилот 737 Max может не отключиться во время нештатной ситуации.
Первая реакция о наличии технических проблемах поступила от пилотов почти сразу. Будто бы обидевшись, компания Боинг решила обучать пилотов с помощью бытовых планшетов, а не на тренажерах. Возможно, компания не среагировала на обращения пилотов, чтобы выглядеть хорошо, для продаж, возможно, она решила сэкономить.
После пилотов о проблемах заговорили журналисты. Всё громче с каждым падением самолётов. Компания Боинг не слышала и их. В конце концов, эксплуатация лайнера была приостановлена по всему миру на несколько лет. Проблемы, конечно, были решены, однако… 737 MAX —это очень невесёлый пример неторопливости решения проблем.
Здесь по идее надо выразиться матом, но увы, здесь читают и приличные люди.
Внедрение процесса «Управление проблемами» повышает скорость управления предприятием. При этом существует типовой процесс и тот, который мы создали в результате авторской доработки процесса управления проблемами из ITIL.
Ещё есть идеальный процесс управления проблемами, не внедрённый. В голове. С участием нейронной сети. Который позволит ускорить управление предприятием в десятки раз.
Возможно, это поможет обогнать Америку. :)
В последнее время почему-то хочется обогнать Америку. И выпить красного сухого. И материться вечерами. Под луной.
Процесс Управления проблемами состоит из нескольких этапов:
Регистрация проблемы. Обеспечивается тотальная регистрация проблем и всё предприятие видит проблематику. Классифицированную, оценённую, прогнозируемую. Видна, протекающая крыша и отсутствие лицензий в ИТ.
Анализ и диагностика проблемы. Проблемный сегмент предприятия анализируется, ищутся причины сбоев. Процесс обеспечивает оперативность диагностики. Бывает информационная система сбоит годами, ИТ-шник разводит руками, к этому все привыкают и перестают материться. Затем ИТ-шник меняется, приходит какой-то студент, обнаруживает причину и устраняет. Процесс делает так, чтобы люди меньше разводили руками.
Поиск/разработка готовых моделей решения проблем. Процесс рекомендует заранее договариваться о том, как решать проблему, в случае её возникновения. Набор сценариев решения проблемы избавляет предприятие от коммуникативных и трансакционных издержек, к примеру.
Решение проблемы (реализация изменения). Оптимизируется проектирование, согласование, модификация решений и т.п.
Разработка обходного решения. Пока проблема не решена, сбои/инциденты устраняются в соответствии с разработанными заранее обходными решениями сбоев/инцидентов.
Эскалация проблемы. Если проблема не решается в рамках линейного подразделения(сектора, отдела и т.п.), она эскалируется наверх или в другое подразделение.
Решение организационных проблем. Происходит анализ организационных причин сбоев/инцидентов и корректируется организационная архитектура предприятия.
Контроль качества решения. Если после решения проблемы возникает повторный сбой—проблема возвращается на доработку.
Утилизация/рефлексия. Происходит анализ влияния решения проблем на предприятие в целом.
Не стоит это зубрить. Всё равно забудете. Просто имейте ввиду, что вы прочитали нечто умное.
Реализация эскалации и решения организационной проблематики—это, как раз один из авторских результатов моей команды.
Схематично эскалация выглядит так:
На большинстве предприятий процесс управления проблемами, не «доходит» до руководителей среднего и верхнего уровня. Поэтому всегда есть тысячи «зависших» проблем, которые невозможно решить без привлечения руководителей среднего и верхнего уровней.
На большинстве предприятий не выстроена логика, при которой повторяющаяся техническая проблема линейного уровня становится организационной проблемой. И это не очень хорошо, с одной стороны. С другой стороны, на предприятиях Америки тоже бардак. Значит можно обогнать :).
Что такое процесс управления проблемами? Любой процесс состоит из двух частей: из закона, в виде регламента и схем и людей, соблюдающих закон. А люди—это сложно...
На вопрос: «А чем ты занимаешься?» Я отвечаю, что развиваю технологии решения проблем. Ответ для большинства непонятный, вызывающий ощущение подвоха. Если просят объяснить попроще, я говорю, что я —менеджер.
—Все менеджеры—мудаки, а технари—молодцы, —иногда звучит нехитрый вывод.
—Согласен с вами, до свидания, —говорю я в таких случаях и в зародыше решаю проблему общения с неприятным человеком.
Я отлично понимаю тех, кто воспринимает менеджеров, как мудаков. Интеллектуальные усилия таких людей направлены на производство, сопровождение оборудования, ИТ инфраструктуры. Остальное —не важно. Это по своей специальности они изучают литературу, приобретают опыт, а о менеджменте они судят поверхностно, по комиксам из сообщества «Сова — эффективный менеджер», к примеру. Будучи молодцами в той или иной области, мы часто воспринимаем себя молодцами везде. И вызываем улыбку.
Операционный блок традиционно отрицательно относится к любому менеджменту. Поэтому, при внедрении чего-то связанного с менеджментом технологий или процессов, нужно учитывать это, вызывать доверие и объяснять очевидного на пальцах.
Вызывать доверие и объяснять очевидное на пальцах должны руководители, административный сегмент… У которого традиционно сложности с доверием сотрудников. Которые очень негативно воспринимают менеджмент… Отсутствие доверия между руководителем и сотрудников—это одно из серьёзнейших препятствий для повышения скорости управления.
Есть ещё нюанс: подразделения административной вертикали часто ставят политические интересы выше интересов предприятия.
Очень часто за высокой вывеской политических интересов скрываются детские комплексы и желание самоутвердиться. Эхбл.
История про то, как политические интересы оказались важней.
Однажды Канадские политики заметили пробки на паромной переправе. Они поразмыслили и решили разобраться с проблемой путём постройки скоростных паромов. Возникли деньги. У местной компании(это важно) заказали три скоростных парома из местного(это важно) алюминия. Запланировали перестройку терминала и новые автодороги. Создались рабочие места и надежды избирателей. Старались выжать все политические выгоды: создать новые рабочие места, развить местную экономику(верфи, алюминий). Канадские политики не учли, что верфи, на которых были заказаны паромы из алюминия, не обладали технологиями строительства таких паромов. Максимум, что верфи умели из алюминия— это небольшие рыболовецкие катера. «Пусть! Научимся и разовьём судостроение»,— сказали канадские политики. И :)
Стоимость паромов выросла вдвое: с 210 миллионов долларов до 460. Их построили на три года позже задуманного.
Паромы получились быстроходными, как и хотели, но:
Скоростные паромы потребляли в два раза больше топлива, чем обычные. Они оказались убыточны.
Особенность скоростных двигателей была в том, что их крыльчатка ломалась от мусора, который находился в воде. Паромы приходилось постоянно чинить.
Если паром двигался на полной скорости, то возникала огромная волна, разрушавшая прибрежные причалы, лодки, имущество в терминалах. Паромам запретили большую скорость на большей части маршрута.
У новых паромов возникли проблемы с балансировкой грузов. Погрузка занимала больше времени, чем на обычный паром.
Открытая палуба была маленькой, пассажиры ютились в каютах, а там было душно и жарко из-за мощных двигателей. Пассажиры опасались перевозить домашних животных на этих паромах.
Через несколько месяцев после запуска проект скоростных паромов признали провальным. На смену одним канадским политикам пришли другие. Новые политики сдали на металлолом три парома стоимостью 460 миллионов долларов. Новые политики оказались не умнее старых: за металлолом получено всего 19 миллионов долларов — в 24 раза меньше, чем потрачено. При этом канадские политики ухитрились не заметить, что Индонезия хотела купить эти паромы за 88 миллионов долларов. Журналисты премного изумились от таких нелепых поворотов.
Приведённая гротесковая ситуация показывает, как политические интересы руководителей мешают здравому смыслу. Печально, но руководители (административный сегмент) тоже совершают катастрофические глупости. Чтобы руководители не гнали против здравого смысла, решение критических организационных проблем должно курироваться первыми лицами.
Над канадскими политиками очень хочется глумиться матом, но, увы, здесь читают и приличные люди.
Я всё чаще задумываюсь бредовой, на первый взгляд мыслью о том, что за счёт массового совершенствования процессов управления, теоретически, можно обогнать Америку. Их методологии управлений имеет недостатки. Они разрознены, часто оторваны от жизни, поверхностны. Разработанные на коммерческой основе, для продажи, они имеют ряд существенных недостатков в части применимости и эффективности. Устранение этих недостатков в отдельно может существенно повысить оперативность управления. И обогнать Америку. :)
Да, пожалуй, на вопрос: «А чем ты занимаешься?», я буду говорить, что пытаюсь обогнать Америку. Понимая, что гоню против здравого смысла.
Резюме: мы узнали цели и основные подпроцессы процесса управление проблемами. И то, что операционное ядро не любит менеджеров, а руководители делают глупости по политическим причинам.
Про карьеру. При построении карьеры, важно уметь говорить с вышестоящими руководителями на языке их проблем. Если вы находитесь в операционном ядре, нужно уметь говорить на языке организационных проблем, если вы находитесь в административном сегменте, вы должны уметь говорить на языке стратегических/политических проблем: развитие, инвестиции, госрегулирование и т. п. С точки зрения моей личной философии, масштаб проблем, решаемых человеком определяет масштаб этого человека.
Что значит говорить на языке проблем? Это значит не просто брякнуть о косяке. И крикнуть: «Шеф, Усё пропало!» . Нужно знать организационные/политические причины возникновения косяка и ущерб вызываемый данными причинами. Нужно знать возможные сценарии/модели решения проблемы, нужно знать как быть, пока не устранены/минимизированы причины проблемы.
Если говорить на с вышестоящими руководителями на языке из проблем, то можно создать впечатление человека осведомлённого в области управления. Что увеличивает шансы к повышению.
Заметили, как много нужно знать для построения карьеры? Это, на самом деле,—не трудно. Со временем научитесь.