Формализация управления. В поисках «серебряной пули». Часть 3

Из всех монстров, которыми наполнены кошмары нашего фольклора, самыми страшными являются оборотни, поскольку нас пугает неожиданное превращение того, что нам известно, в нечто ужасное. Мы ищем серебряные пули, которые могли бы волшебным образом уложить оборотней наповал.
Фредерик Брукс

- Я духов вызывать могу из бездны. - И я могу, и каждый может, вопрос лишь, явятся ль они на зов?
Шекспир, король Генрих IV

В первых частях статьи было обсуждено несколько мифов, связанных с формализацией систем управления. Основное содержание этих, усиленно тиражируемых рынком поставщиков, мифов сводиться к одной формуле: «для решения задачи быстрого и устойчивого повышения эффективности организации и ее управления «серебряная пуля» есть, и она называется «формализация». Продолжая обсуждение поднятых в первых частях статьи вопросов, поговорим о том, существует ли оптимальный уровень формализации управления. Есть ли правильная система, которая подходит многим, если не всем, а также, есть ли идеальные (правильные) процессы, которые можно один раз спланировать и внедрить (например, скопировав у конкурента, лидера отрасли). Получит ли организация после этого на годы устойчиво и эффективно работающий механизм управления, процессов, ИТ. Далее, закончим статью небольшим рассуждением на тему, если формализация - это не "серебряная пуля", то зачем тогда она вообще нужна?

Краткая предыстория и пару капель желчи

Прежде всего, пару слов на тему аллюзий о серебряной пуле. Наверное, об этом стоило рассказать в самой первой части статьи, но там попалась под руку байка о конференции, а идея про нежить, в общих чертах, и так понятна. Но, на всякий случай, чуть более подробно о программистах, оборотнях и драгоценных металлах.

Книга Брукса «Мифический человеко-месяц» (еще не переведенная) была одной из первых книг в стиле бизнес-образование (в западном понимании), которая попала мне в руки в молодости. С момента ее написания и до текущего времени веселая компания, к которой помимо Брукса можно причислить Йордана, ДеМарко, Харела, Кокса и некоторых других, менее известных личностей, обсуждала, с переменным успехом, пути повышения эффективности, качества, снижения стоимости и времени разработки, а также снижения стоимости рисков в области создания программных систем. Тема поиска «серебряной пули» то разгоралась с новой силой, то чуть затухала достаточно надолго (возможно она до сих пор еще не закрыта). Но, на тот момент, когда меня это интересовало, уважаемые зачинатели так и не смогли однозначно сформулировать, есть ли хотя бы потенциальный кандидат на роль универсального «решателя» озвученных выше задач.

Аналогичная тема поиска абсолютного решения, которое сможет качественно повысить эффективность, гибкость и мобильность, снизить транзакционные издержки и время, необходимое для внедрения изменений в практику быстро и по понятному рецепту в системах управления компаниями, появилась (правда, значительно позже) среди менеджеров и поставщиков околоуправленческих решений. В разные моменты времени на позиции «серебряной пули» претендовали (а некоторые и сейчас претендуют):

• Прикладные информационные системы (MRP II, ERP, SRM, SCM, ECM и проч.);

• Инструментарий, используемый при формализации (ARIS, BPM, и все что за ним стоит: BPMS, BPMN, ACM и т.д.);

• Идеи и концепции (РБП, шесть сигм, управление качеством в разных ипостасях, бережливое производство и т.п.).

Так или иначе, именно влияние модных поветрий, вызванных разработчиками и адептами этих уважаемых названий, присутствует во всех перечисленных ранее мифах. Стоит ли упоминать о результатах нашествия наваждений и поверий в чудеса? Так, например, только Toyota смогла достичь того, чего она достигла, не ища волшебных систем, а просто развивая свою производственную систему в течение нескольких десятков лет.

Каких только потом звучных названий «на продажу» не придумали: DAO TOYOTA, TPS, ЛИН, бережливое производство, бережливый офис, бережливый сервис, 5S, быстрая переналадка, TPS+6 sigma и проч.

Хотя сначала длительное время над идеями японцев (справедливости ради стоит заметить, что методы, которые использовал Таичи Оно в TOYOTA, работают не только там) потешался весь автомобильный мир. А спустя некоторое время и Ford, и Chrysler, я уж не говорю про Российскую гордость: автогиганты ГАЗ и ВАЗ, все отметились в набеге за волшебным знанием и запустили свои производственные программы, аналогичные японским. Правда, ненадолго и с совершенно (мягко скажем) неровным результатом. Все неудачи потом были объяснены вымаранной цитатой из Киплинга, что «запад есть запад, восток есть восток и вместе им не сойтись никогда». Хотя, честно говоря, мне кажется, что Киплинг был бы удивлен дважды: весьма фривольной трактовкой и использованием его стиха в контексте автопрома. Если так пойдет дальше, то финансовые аналитики начнут ссылаться в своих отчетах на «Пак с холма Пука», а политологи на «Книгу джунглей». Хотя, вроде, нечто подобное недавно уже было?

Обязательный «anyway»

Во избежание досадных непониманий (в который раз), стоит отметить, что я считаю все из перечисленных выше названий (систем, программ, нотаций, подходов) весьма удачными инструментами, проверенными на практике, каждый из которых может давать блестящие результаты. Более того, если посмотреть на сайт компании, где я работаю, то можно увидеть, что все эти инструменты используются в нашей работе в различных проектах, разных компаниях, всех отраслях. Так в чем же подвох? Зачем стоило полторы страницы их "хаять"? Дело в том, что, с моей точки зрения, не стоит подменять решение задачи инструментом. Другими словами, я предлагаю разделять две совершенно противоположные ситуации, описанные ниже. И самостоятельно определять, которая из них кому подходит больше.

В первом случае, например, вы решили высадить на даче чудесные цветы, которых нет ни у кого, из семян, привезенных лично из Бенгалии. Тогда, для получения рассады в мае, вам, по зрелому размышлению, надо сколотить в конце февраля 2 деревянных ящика размером 120х50х30. Ведь цветы необыкновенные и для них нужны такие же необыкновенные ящики ручной работы. Несомненно, для того, чтобы сделать ящики (в феврале) вам понадобится молоток. Становится понятно, какой молоток нужен (обыкновенный слесарный подойдет), что еще надо (гвозди, доски, земля, пиво), что делать после и какие выгоды от этого всего вы ожидаете (ну не в виде блестящего молотка в домашней коллекции инструментов – это точно).

Второй случай не менее гипотетичен и встречается не реже первого. Допустим, вы прикупили какой-нибудь мощный девайс, например, бензопилу. Возможно, вы с детства о ней мечтали, возможно, она просто запала в душу своей никелированной цепью или продавец попался с огоньком, по фамилии Нахальный, и зажёг идеей. И вот вы, счастливый обладатель этой пилы, заправили ее бензином, и она лежит в багажнике вашей машины. Что только с ней делать? И дачи у вас нету, и для шашлыков не сезон (февраль же)? А пила-то вот она, рядом, зовет, и манит. Руки просто чешутся. И логика подсказывает: надо использовать, деньги за нее уплачены немалые. А потому, хотя и других задач полно, но все они подозрительно начинают напоминать вдруг дрова для распила. Ну, в хорошем смысле.

Так как же с формализацией?

Итак, все объяснения даны и реверансы сделаны. Давайте вернемся к теме статьи. Как бы автор поступил, столкнись он с проблемой, навязанной ему руководством, или с чем-то из своего бизнеса? Вот есть некий актив, который нужно существенно улучшить, и почему-то все усиленно говорят про формализацию управления. Что делать? Давайте попытаемся набросать примерный план, который, возможно несколько упростит поход за формализацией систем управления.

Этап первый. Давайте на время забудем о формализации. По сути «формализация» - это молоток или ящик для рассады. Сначала стоит подумать о том, что хочется получить для бизнеса в итоге. Какими профитами это должно обернуться для компании. Обязательно в цифрах. Цели должны звучать именно так – «что-то должно измениться не менее, чем на ... или в ... %». Пока инструментов (молотков, ERP, BPMN, СЭД и проч.) и в помине нет.

Этап второй. После того, как есть понимание в цифрах, чего хочется получить, надо придумать программу (идею) того, как эти цифры могут быть достигнуты. Надо разработать основные ключевые моменты решения и прикинуть основные потребные для этого ресурсы (ну что-то типа того, что сажаем и растим сами, ящики делаем сами, есть семена и финансы). Тогда же стоит разработать несколько сценариев, прикинуть их стоимость и проанализировать риски, которые могут возникнуть при реализации каждого из них (может проще купить рассаду на рынке в мае?). На этом этапе стоит проанализировать ограничения вашей программы и подумать о возможном влиянии корпоративной культуры (согласится ли супруга на рассаду из магазина – ведь семена-то покупала она; как отнесется кошка к ящикам с землей в прихожей). Итогом этапа будет приоритезация выбранных сценариев, понимание их ограничений, стоимости и рисков. Инструменты пока даже и не видны, но уже появляется их смутное предчувствие.

Этап третий. В нем надо разработать поэтапный план реализации программы из второго пункта («deadline» май – рассада, «milestone» февраль – ящики). Именно на этом этапе появляются окончательные требования к инструментам (молоток нужен и достаточно того, что продают в хозяйственном отделе универсама, основной критерий выбора – цена; молоток нужен не позже февраля). И пора приступать к их выбору. Вот тут и может появиться описание работ по формализации, с четкими требованиями, границами, ограничениями и конечными целями (для чего они затеваются). Не вообще, не абстрактно «правильных», а именно нужных для решения выбранной задачи. На основании этого описания стоит искать, выбирать, торговаться. И тут поручается целый список работ, которые надо сделать в определенной последовательности с заданными промежуточными результатами.

А есть ли план «Б»?

Сторонники второго варианта, прочитав предыдущую главу, одновременно воскликнут: «Головняк! Это столько всего сделать надо, а людей и времени на это нету. Есть решение проще простого: надо взять правильное, готовое решение». Ну, понятное дело – бензопилу. Доводов этому приводиться несколько:

• Первый довод – мы можем что-то важное упустить при своем планировании. Либо из-за того же цейтнота, либо потому, что опытных сотрудников недостаточно. Но в любом случае есть мировой опыт решений такого рода, и давайте мы его используем;

• Второй довод – зачем время тратить, все уже давно придумано до нас. Причем, не доморощенно, не местечково, а фундаментально, проверено на опыте передовых компаний, построено на века, одним словом, по не-нашему (в зависимости от склонностей руководителя – цивилизованно, по-западному, по-японски);

• Третий довод – а кто будет работать, реальное дело делать, пока все этой ерундой будут заниматься?

• И самый веский, на мой взгляд, как правило, не декларируемый, но зачастую подразумеваемый наемными менеджерами: «Ни одного менеджера еще не уволили за то, что он выбрал решения от IBM».

И далее следует вывод, что правильное готовое решение решит не только существующую проблему, но и другие, которые еще не появились или с которыми пока еще не решились бороться. Автоматически. Просто фактом своего внедрения на предприятии.

Хочется задать вопрос, если есть такое решение, то почему же тогда уже все не перешли на него и не процветают одинаково в своей деятельности, устранив большинство выявленных проблем? Каждый может выбрать устраивающий для него ответ на этот вопрос. Я лично считаю, что плана «Б» нет. Ведь нет двух одинаковых компаний, нет двух одинаковых проблем в этих компаниях, нет двух одинаковых наборов персонала, заинтересованных лиц, клиентской базы, базы поставщиков. А значит поиски решения одинаково хорошего (без изменений, донастроек, «примочек» и проч., которые превращают решение в конструктор «сделай-сам») для всех, или многих, или нескольких компаний, прочем, как и поиск панацеи, философского камня или вечного двигателя, превращается в увлекательное, но мало результативное занятие.

Поэтому для меня ответ на первую часть вопросов, заданных в начале этой части статьи, – «нет». Не существует оптимального уровня формализации управления, идеальных (правильных) процессов, которые подходят сразу всем, некоторым, нескольким, и даже хотя бы двум компаниям. А потому процесс формализации «по шаблону» не подходит для достижения каких бы то ни было целей, которые компания поставила себе:

• Реальных, например, увеличение прибыли, сокращение времени обслуживания одного клиента, уменьшение брака на Х%;

• «Воздушных», например, повышение управляемости и прозрачности.

В том случае, если принято решение о необходимости формализации системы управления, то использовать стандартные, типовые, «правильные» решения можно только тогда, когда есть детально продуманная и четко спланированная программа их «приручения», если есть желание получить какие-то реальные, положительные для компании результаты. И тогда, даже в случае с «воздушной» постановкой задачи, присутствует реальный шанс получения внезапных, неожиданных и нежданных (и, может, от этого еще более желанных) результатов. Решение должно быть выстраданным, разработанным (в крайнем случае, адаптированным). Просто внедрить SAP «как у всех», BPMS «как советуют разработчики» нет никакого смысла. Все равно или выбросите, или будете переделывать (донастраивать) для своих целей, потратив при этом гораздо больше времени и ресурсов, нежели с самого начала выбрав вариант «А».

Кому подходит

Теперь давайте разберемся с тем, а кому это вообще надо? Ну, в смысле, всем ли подходит одинаковое программное обеспечение и методологии (о том, что одинаковые "пути-решения" подходят далеко не всем, мы уже обсудили ранее). Очевидно, что в жизни, даже если мы решаем одинаковые проблемы (например, поиск осенней обуви), для разных людей мы находим разные решения (папе ищем обувь для охоты-рыбалки, маме для выхода в город и к подругам, а бабушке - для похода по главной улице в деревне). Почему-то это правило не всегда срабатывает вне рамок обыденной жизни. Зачастую приходится просто удивляться восторгу в глазах собственников, когда они, например, воодушевились идеей в качестве инструмента автоматизации внедрить «взрослую» ERP (например, Oracle или SAP). Хотя это явно системы не «по ноге» бизнесу. Ну, глупо носить итальянские туфли 44 размера, когда еще ходишь в детский садик, и нога у тебя от силы 18-го. И дело даже не в цене. Просто сейчас это неудобно, вредно, мешает. Сандалий (хотя, конечно, по стоимости 1С уже переросло сандалии) будет достаточно. Причем, и на ближайшую перспективу.

И суть не только в том, что стоит при выборе решения учитывать размер бизнеса компании. Здесь все несколько сложнее, чем с обувью. Очень важно учитывать целый ряд параметров организации и ее окружения, для того, чтобы найти верное решение. В данном случае, скорее верно говорить о том, что любая организация:

• Существует на какой-то стадии своего жизненного цикла (как у человека - молодость, зрелость, старость);

• Действует в окружении своих потребителей и партнеров, которые формируют сложность рынка и окружения (изменчивость внешней среды, способности к адаптации);

• Имеет какие-то внутренние предпочтения и особенности, которые формируются характером собственников, корпоративной культурой, особенностями нанимаемого типа персонала, вовлеченного в деятельность компании;

• Выстраивает свою деятельность, исходя из стратегии и понимания своего будущего;

• В конце концов, обладает определенными ресурсами (в том числе и финансовыми).

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

В противном случае, может случиться, что для компании в 50 человек (включая собственника, его водителя и уборщика снега), осуществляющей розничную торговлю в паре маленьких магазинчиках «у дома» для «формализации управления» будут создано 12 регламентов, 34 инструкции (не считая должностных). Их общий объемом составит несколько сотен печатных листов. Когда я увидел подобное творчество, особенно меня изумила инструкция для дворника на 12 листах. Далее. Очевидно, что одни и те же решения явно не будут «работать» одинаково в медицинской клинике и в страховой компании, например. Профессиональному хирургу и продавцу полисов ОСАГО нужны не просто инструкции, описывающие разную деятельность. Сам принцип формализации работ группы специалистов после многих лет института, интернатуры, ординатуры, регулярной практики иной, нежели студентов на подработке. Попробуйте создать детальную, пошаговую инструкцию для играющего в шахматы и сравните ее с технологической картой изготовления резьбы на болтах. И дело даже не в уровне подготовки и знаний (хотя и он не менее важен), дело в том, что организация работ совершенно разная. А значит, цели, подходы, результаты формализации будут разные.

Пару слов о внешнем окружении. Как правило, при осуществлении мероприятий, связанных с формализацией процессов, бизнеса, системы управления о нем (этом окружении) задумываются в последнюю очередь. Действительно, ведь мы же тут внутри что-то меняем. Какое отношение рынок к этому имеет? Или нет? В качестве примера приведу историю о том, как на моей памяти один собственник весьма уважаемой компании долго и упорно пытался жестко формализовать (как на конвейере) процесс продаж и клиентского обслуживания. Для этого работу старательно разбивали на стадии, описывая результаты; назначали каждой стадии KPI и ответственных и, параллельно, насаждали «фашистскими» методами CRM в организации. А основной бизнес организации был в том, что она проектировала, изготавливала и продавала уникальные технологические решения под изощренные требования заказчика. Ну, не согласен он (заказчик) был с введением типизации, инструкций, которые не позволяли ему получить ожидаемый им результат с ожидаемым качеством и в ожидаемые сроки. Потому, что заказчик на этом рынке ожидает комплексного решения своей нетривиальной задачи. Задачу эту, оказывается, было легче решать не конвейерными технологиями, а проектной работой. Но кому было дело до этого в пылу изменений: сказали формализовать, а, значит, описывать процессы. Выбрать тип формализации, чтобы далее формализовывать не процессы, а проекты, позабыли.

Как реализовать все это

Отдельной и реально сложной задачей является реализация этих планов. Об этом в этой статье будет сказано немного. Во-первых, потому, что реализация такой программы - это всегда индивидуальное решение и можно приводить только некоторые общие подходы. А во-вторых, программа реализации очень сильно зависит от того, что именно и для чего будет реализовано.

Но в любом случае есть несколько непреложных истин. Например, даже если выбран план «Б», но он сложнее внедрения клиент-банка, то провести в реальный бизнес изменения (будь то новая программа или формализация бизнес-процессов разных мастей) «приказом» по компании разработанного чего-то-кем-то (либо своими специалистами «чудо отдела», либо консультантами) не получится. И никто за заказчика его часть работы не сделает. Ни разработчики, ни внедренцы, ни консультанты. В лучшем случае, они смогут помочь заказчику запуститься быстрее, дешевле, качественнее, нежели он это делал сам в одиночку. В худшем случае, они заберут денег и уйдут. И оставят заказчика один на один все же разбираться с тем, что он купил «пампукскую хрюрю» или новомодную игрушку для больших детей.

Следующее замечание. Очень важно еще даже до начала внедрения разработанных изменений разобраться с тем, как эффективно привить эти предложения к той корпоративной культуре, которая царит в компании. Причем, как ни странно, эта задача касается не только организационных изменений, но и «простого» внедрения нового элемента (перехода на новый элемент) информационной системы (план «Б»). Как говорят опытные внедренцы от ИТ (в процессе внедрения): автоматизация не должна облегчать жизнь персоналу, но должна что-то упростить для компании в целом. А потому, добро пожаловать в мир, который приказами и инструкциями не регулируется. Историй о том, как компания потратила кучу ресурсов и времени, внедрила что-то, а потом, спустя некоторое время, от этого отказалась, предостаточно в сети.

Итоговый трюизм. Стоит быть готовым к тому, что ничто и никогда не реализуется так, как было запланировано с начала. Потому обязательно внедрением должен заниматься человек, который умеет управлять происходящими изменениями, но все же приведет проект к намеченной цели. И роль этого человека (в простонародье называемого менеджером проектов) гораздо сложнее и многограннее командира заградотряда НКВД. Крики и ругань на тему «ничего не знаю, должно быть так, как я сказал», «я начальник, вы все дураки», «я лучше вас всех знаю, как сделать всех счастливыми» явно не помогут. Задача этого человека - по необходимости корректировать разработанный план с учетом реалий и фактов текущего (как минимум), а также неопределенностей будущего (как максимум). Его задача, все же не четкое следование плану, а достижение поставленной перед проектом цели. И явно, что целью является не молоток или ящики из примера выше. Скорее, целью является радость супруги при получении букета экзотических цветов с клумбы у собственного коттеджа. Ну или что-то вроде того.

Надолго ли

Еще одна не новая идея заключается в том, что нет ничего вечного под Луной. Это относится и к любым нововведениям, программам, системам. А потому, любая организация, например, "Построенная навечно", или иная успешная компания, славилась совсем не тем, что ее мудрый основатель однажды «угадал с заменой», что-то выстроил однажды, и потом все долго и счастливо получали бонусы и дивиденды. Скорее, все они славились тем, что были постоянно в поиске чего-то для себя важного. Поэтому, надо вовремя понимать, что мир вокруг меняется, клиенты требуют нового, сама компания изменилась, поменялось ее окружение и его требования (конкуренты, технологии, социум). А значит, снова планировать изменения. Не потому, что что-то было сделано не так ранее (хотя и такое может быть). По-моему, основной конструктивный драйвер изменений все же должен быть не в том, чтобы что-то исправить в старом. Скорее, надо сделать что-то новое.

Вместо эпилога

Одна из проблем очень многих людей в том, что они не допускают мысли, что могут чего-то не знать или сделать не так, или хуже кого-то. Они уверены, что знают, как надо делать правильно. Они не готовы слушать никого, кто имеет иное, отличное от их собственного, мнение. И именно это ведет к еще более глупым ошибкам. В качестве иллюстрации стоит вспомнить байку, с которой началась первая статья про презентацию. А ведь были правы скептичные организаторы конференции. Хотя бы в одном. В 30 минутную презентацию все эти три статьи точно не поместились бы.


Станислав Тульчинский tulchinsky@b2b-group.ru

mail@b2b-group.ru

Создание сайта —
студия BlackBox
Copyright © b2b-group При копировании информации, ссылка на источник обязательна. Полное либо частичное копирование информации с этого сайта на другие ресурсы разрешено только при наличии видимой ссылки на наш сайт.