Извините за самонадеянность, но хочу дать несколько советов компаниям, у которых есть стремление к совершенствованию и ресурсы, чтобы это стремление реализовать.
Я вижу, как руководители, задумывающиеся о возможных путях усовершенствования для своей компании, буквально подавлены огромным числом разнообразных концепций, стратегий и рецептов в области бизнеса и менеджмента. Чтобы оценить масштаб стоящей перед ними проблемы выбора, взгляните на страницу Википедии с обзором современных бизнес-стратегий. Что лучше, что даст максимальную отдачу на инвестированный рубль - система Тойоты? процессное управление? ERP? CRM? система сбалансированных показателей? или может быть, какая-то из десятков других альтернатив?
Причем многочисленность возможных путей усовершенствования - это только часть проблемы. Плохо еще и то, что все эти концепции и методологии не укладываются в единую картину. Как правило, гуру менеджмента не любят очерчивать границы своих концепций и распространяться о смежных дисциплинах. Агрессивно и напористо каждый “продает” свой рецепт как всеобъемлющий и единственный заслуживающий внимания.
К чему это приводит?
- Синдром буриданова осла: руководитель, склонный к перфекционизму, впадает в ступор и не предпринимает ничего, так как он не в состоянии сделать оптимальный выбор.
- Синдром “серебряной пули”: руководитель с авантюрной жилкой принимает за руководство к действию первую теорию, которая его “зацепила” и для реализации которой хватает ресурсов. Что, в общем, является стратегией лучшей, чем первая. Побольше лидерских качеств и здравого смысла, поменьше фанатизма - и практически с любой теорией можно добиться успеха.
Для сравнения посмотрим на смежную область программного обеспечения для бизнеса и ИТ-консалтинга.
ИТ-шников тоже есть за что критиковать, и их обещания тоже надо делить на 4 (если не на 16), но есть существенное отличие: информационные технологии структурированы. Есть общепринятый т.н. стэк информационных технологий, который выглядит примерно так:
На каждом этаже стэка есть множество альтернатив и конкурирующий поставщиков, между которыми можно выбирать. Но мы не выбираем, скажем, между прокладкой кабельной сети в здании и приобретением CRM-системы. Согласитесь, глупо было бы делать выбор в пользу CRM на том основании, что с ней работают продавцы и от нее поэтому есть реальная польза, а сеть обычному пользователю не нужна, и он про нее вообще ничего не знает.
Но ведь примерно это зачастую происходит при выборе концепций бизнеса и менеджмента! Поэтому для них крайне полезно ввести понятие стэка управленческих компетенций. (Мне кажется, термин “компетенция” тут более уместен, чем “технология”, поскольку в бизнесе и менеджменте по сравнению с ИТ сильнее гуманитарная составляющая.)
Некоторые примеры:
- управление отношениями с клиентами, производственное планирование, бюджетирование находятся на уровне функционального управления (относясь к продажам, производству и финансам соответственно)
- BPM находится на уровне процессного управления (не путать с программным обеспечением BPMS, которое принадлежит уровню промежуточного программного обеспечения стэка ИТ)
- система Тойоты, Lean, Шесть сигм и Теория ограничений находятся на уровне концепций
Взаимосвязь между уровнями тут та же, что и в ИТ: нижний уровень без верхнего лишен смысла, верхний без нижнего - технологичности.
- Глядя сверху-вниз, нижний уровень является для верхнего обеспечивающим. Это “приводной ремнень”, преобразующий абстрактные идеи в конкретную деятельность конкретных людей, тем самым доводя эти идеи до практического результата.
- Глядя снизу-вверх, верхний уровень - это то, что придает смысл деятельности нижнего уровня и повышает его отдачу.
Проиллюстрирую эти взаимосвязи примерами:
- Нормальная компания не может существовать, если она не обладает компетенциями в области продаж, производства или оказания услуг (функциональный уровень).
- Компании, достигшей определенного размера и уровня зрелости, необходимо прилагать дополнительные усилия для координации деятельности функциональных подразделений в рамках сквозных бизнес-процессов или проектов (уровень процессного и проектного управления). Иначе функциональные подразделения все больше и больше начинают работать не на клиента, а на себя.
- Теория цепочки создания ценностей (уровень концепции) задает цель для проектов в области бизнес-процессов (уровень процессного и проектного управления). Дело ведь не только в том, чтобы все делать как положено и без простоев (”do things right”), но и в том, чтобы делать то, что востребовано (”do the right things”). Процессное управление, лишенное концептуального уровня, тяготеет к тому, чтобы бесконечно шлифовать бизнес-процесс, не задаваясь вопросом - а то ли вообще этот процесс дает на выходе?
- Теория ограничений (уровень концепции) предлагает алгоритм (”пять шагов”) поиска и выбора такого бизнес-процесса, усилия по повышении производительности которого дадут максимальную отдачу с точки зрения итоговых показателей компании, т.е. прибыли в настоящем и в будущем. Без концептуального уровня процессная инициатива вырождается, например, в анализ и моделирование бизнес-процессов на шести уровнях иерархии - занятие само по себе увлекательное, но бесплодное с точки зрения итоговых показателей.
Итак, компетенции нижних уровней обеспечивают реализацию компетенций верхних уровней. Уместен вопрос: а есть ли польза от компетенций верхних уровней в отсутствие нижних?
Полагаю - есть, но ограниченная:
- Вы можете начать внедрять процессное управление, не имея полноценного управленческого учета, но ваши успехи на этом пути окажутся ограниченными (если вообще они будут): вы быстро выясните, что любой бизнес-процесс оперирует бизнес-объектами, поддерживаемыми базами данных и корпоративными системами. Например, если вы возьметесь за процесс “от обращения до заказа”, не имея CRM-системы (обеспечивающей функциональную компетенцию), то через некоторое время вы обнаружите, что в рамках проекта BPM вы разрабатываете собственную CRM-систему. (Что, кстати, иногда бывает оправдано, но все же надо отдавать себе отчет, что собственная разработка, скорее всего, будет уступать готовым CRM-системам по функциональности.) BPM - это в основном для тех, у кого ERP и CRM уже есть, а счастья еще нет.
- Вы можете начать внедрять Lean, не обладая компетенцией в области процессного управления. В этом случае вы можете добиться успехов на уровне отдельных подразделений, но при попытке распространить эту методологию на компанию в целом у вас возникнут проблемы, так как ключ к разрешению противоречий между подразделений - это кросс-функциональные бизнес-процессы и BPM.
Вывод: начинать с компетенций верхнего уровня можно только с целью создания технологического задела. В полном объеме их преимущества реализуются лишь тогда, когда наличествуют необходимые компетенции нижнего уровня.
К сожалению, наличие уровней управленческих компетенций и взаимосвязь между ними слабо осознаются руководителями и консультантами. Полагаю, в этом заключается разгадка некоторых драматических историй неудач.
Вероятный сценарий:
- Предположим, что некая компания A добилась впечатляющих успехов в трансформации своего бизнеса. Сведения об этих успехах стали достоянием публики.
- Консультанты, принимавшие участие в проекте компании A, обобщили опыт, превратив его в новую методологию X, и стали интенсивно рекламировать себя и методологию X, действительно принесшую успех компании A. Примерно по этой схеме появились на свет TQM (Ксерокс), Lean (Тойота), Шесть сигм (Моторола).
- Компания Q решила воспользоваться методологией X и повторить успех компании A. Но книги, посвященные X, достаточно скупо освещают необходимость ее обеспечения компетенциями Y и Z - во-первых, потому, что для компании A это слишком очевидно, чтобы об этом говорить, а во-вторых, любые предварительные условия негативно отразятся на продажах услуг, связанных с X.
- В результате проект компании Q проваливается. Успех A и провал Q объясняется тем, что у A наличествовали компетенции нижних уровней, а Q решила не тратить время на их приобретение, а идти к “успеху” кратчайшим путем.
Непонимание взаимосвязей между уровнями компетенции приводит также к неправильной оценке эффективности инвестиций. Например, известно, что проекты BPM выгодно отличаются от проектов ERP высокими показателями ROI. Учитывая, что ERP соответствует компетенции функционального уровня, а BPM - процессного, это неудивительно. Внедрение ERP дает определенную выгоду само по себе, но вероятно важнее то, что без ERP вы не сможете получить выгоду от BPM и других компетенций верхних уровней. Аналогично, без BPM вы не сможете эффективно реализовать Lean.
Резюмируя, обещанные рекомендации:
- Не беритесь за полномасштабное внедрение компетенции верхнего уровня, не освоив нижние, на которые она опирается - отдача будет ниже, чем вы ожидаете, или ее вообще не будет.
- Внедрив компетенцию нижнего уровня, не останавливайтесь на этом - основной выгоду приносит внедрение компетенции верхнего уровня, опирающейся на ту базу, которую вам удалось создать.
В бизнесе нельзя мыслить только одноходовками - иногда надо просчитывать комбинации, как в шахматах. Думать не только о выигранном материале (сегодняшних прибылях), но и о позиции (приобретении базовых компетенций), и о темпе (способности бизнеса быстро перестраиваться).
Понятно, что временщикам этой игре не научиться в принципе. И еще тут возможна ситуация, когда начали комбинацию вы, а собирать урожай будет ваш преемник.
Отдельная задача - объяснить план многоходовой комбинации акционерам. Надеюсь, что предложенная простая схема уровней компетенции как-то в этом поможет.
Но, подозреваю, главный вопрос - как быть, если жизнь берет за горло? Что ж, “выживают только параноики”. У остальных вечно получается так, что сначала слишком рано, а потом вдруг уже слишком поздно.
Если вдруг вы оказались в болоте, кишащем крокодилами, то приходится думать одновременно и о том, как справиться с ближайшим крокодилом, и о том, как осушить болото.
Следующие заметки развивают предложенную концепцию стэка управленческих компетенций:
Рад, что “набрёл” на Ваш блог. Я занимаюсь внедрением ERP. Наши проекты более масштабны и протяжены во времени, чем BPM и после завершения нескольких проектов я пришёл к следующему выводу - успешным может быть тот проект, который покрывает реальную потребность бизнеса(а не для “выхода на IPO”, к примеру) и “идею” воплощенную в приверженности к одной из (или комбинации) бизнес-концепций. Если спонсор проекта знает что такое BSC и хочет чтобы эти идеи были воплощены и в системе, то это уже задает направление для описания и настройки\программирования и позволяет этой концепции проникнуть на самый низкий уровень управления (в итоге и сама система получается более структурированной а не “автоматизированным хаосом”, как это часто бывает).
На мой взгляд, верхний уровень Вашего стека управленческих компетенций и не уровень во все. Если рассматривать аналогию со строительством, то мы сначала закладываем фундамент дома в виде “функционального управления” (и его автоматизации), а потом начинаем строить здание: с этажами, лестницами, пожарными выходами. Так вот, концепция управления - это не крыша, венчающее здание, а план по которому оно строиться. От самого фундамента (основ) до последних этажей. Она должна прослеживаться на каждом уровне бизнеса и чем раньше - тем лучше
Пётр
Спасибо за комментарий, но Ваше сравнение с планом не готов принять.
Ценность структурирования задачи по уровням абстракции состоит в том, что уровни обращаются друг к другу как к “черным ящикам”. План здания нельзя менять по ходу стройки, а сменить концепцию управления теоретически возможно. Моя идея заключается в том, что какую бы концепцию компания не выбрала, ей не обойтись без компетенции на процессном уровне. В свою очередь, процессный уровень оперирует с бизнес-объектами, реализованными в функциональных системах. Верхний уровень не “проектирует” нижний, он обращается к нему через согласованный интерфейс. Если интерфейс разработан грамотно, то можно заменить нижний, не затронув при этом верхний, или наоборот. SOA в сущности об этом же.
Картинка конечно идеалистическая, но стремиться надо к этому. Компании живут долго, и какой бы замечательный план вы не составили (какую бы концепцию не выбрали), рано или поздно она устареет. Плохо, если единственным выходом в такой ситуации будет пригнать бульдозер - хотелось бы иметь возможность поменять крышу, не снося дом.
Понимание этого приходит с годами, в молодости все стремятся построить дивный новый мир.
Я правильно Вас понимаю, что идеальная последовательность “пути” такая:
1. Сначала автоматизируем функциональный уровень, т.е. просто приходим и приводим в элементарный порядок бизнес-процессы (но не акцентируя на них внимание =), чтобы все “хозяйство” могло работать в одной операционной среде.
2. Автоматизируются сквозные бизнес-процессы, для повышения эффективности
3. На всё это применяется одна из (или комбинация) управленческих концепций для еще большей эффективности?
Я согласен с тем, что верхний уровень “не проектирует” нижний, но, на мой взгляд, самого верхнего уровня (управленческая концепция) нет. Концепция присутствует и на процессном , и на функциональном уровне (я против того, чтобы рассматривать концепцию как нечто автономное), а “замена” как раз происходит потому что мы меняем концепцию, а “автономность” уровней позволяет нам “не сносить все под основание”, а корректировать\изменять их под новый план. Ведь концепция будет успешной (и даст отдачу) только тогда, когда она “прорастет” в компании повсюду, когда как можно больше сотрудников будут осознавать её ценность. Именно поэтому таких успехов добились Тойота, Моторола - их концепции во многом стали синонимами этих компаний. А в случае необходимости по новому плану можно и дислокацию сменить http://www.xieergai.com/2010/01/movehouse/ =)
Пётр
В принципе правильно, только последовательность может быть любой: можно начинать снизу, можно сверху, можно с середины, а можно одновременно с двух концов. Главное чтобы в голове было понимание того, что нужны все компоненты, и того, как в итоге они все должны друг с другом состыковаться и друг друга усиливать.
И я бы поменял порядок слов на “приводим в порядок элементарные бизнес-процессы”.
Нынешняя беда заключается в том, что с бизнес-процессами пытаются разобраться “заодно” и в проектах ERP, и в проектах Lean/TPS. Но бизнес-процессы не прощают любительского к себе отношения - это самостоятельная дисциплина, требующая вдумчивого отношения. В идеале уровень ERP/функционального управления должен быть реализован так, чтобы он обеспечивал некоторый набор примитивов (регистры - счета, склады, центры затрат и т.п. - и меняющие их состояние хозяйственные операции), которые можно комбинировать на верхних уровнях произвольными способами. Сегодняшние системы устроены по-другому - в них “зашита” определенная концепция. Но движение в направлении SOA, которое декларируют все поставщики, по идее должно привести именно к этому.
Не вижу проблем с охватом всех сотрудников. Через каждого сотрудника проходит и функциональный уровень, и процессный, и концептуальный.
В этом деле передвижения недвижимости китайцы не первые - большие дома на Тверской переносились еще в 30-х. Или в 50-х? В общем, давно.
Из Ваших постов я сделал вывод, что движение должно быть именно в таком порядке (пока не автоматизирован функциональный уровень, о процессном управление лучше вообще не думать; пока не налажено управление процессами, концепциями совершенствования бизнеса лучше не заниматься). Но если можно начинать и с верху (и одновременно с обоих концов), тогда это в принципе то о чём я писал.
На счет логики, зашитой в ERP. Да, часто это мешает. Но все же иногда и спасает, поскольку клиенты не “заморачиваются” и перед внедрением ERP не производят улучшений на уровне управления бизнеса. А так эта логика позволяет избежать “автоматизированного хаоса”, который мог бы возникнуть (хотя к сожалению и не всегда).
В этом плане интересно будет посмотреть на Oracle Fusion Applications. Это, по-моему, будет первая ERP реализующая SOA в таком объёме (http://soft.compulenta.ru/468265/). А там глядишь и мой MS Dynamics подтянется.
Вероятно я недостаточно определенно выразился. В оригинальном посте сказано, что от компетенции верхнего уровня в отсутствие нижней польза есть, хотя и ограниченная. Под этим подразумевалось, что сверху начинать можно, но при этом надо прикидывать, в какой момент мы упремся в ограничение снизу, и планировать соответствующий проект. Какие-то отдельные низко висящие яблоки мы сорвем, но чтобы собрать весь урожай, надо сколотить лестницу.
Мне кажется, автоматизация хаоса в проектах ERP случается из-за того, что люди пытаются разобраться с бизнес-процессами, не имея для этого ни адекватного инструмента, ни методологии, ни компетенции. Валят все в одну кучу: клиент вначале вроде говорил об управлении материальными запасами, а на финальной презентации (и хорошо еще, если не в середине проекта) вдруг произносит “да, кстати, а как у вас с документооборотом и с этими, как их, о! бизнес-процессами?”.
Вендоры, естественно, идут на поводу - куда им деваться, “let’s follow the money”. Но если с самим софтом они еще могут что-то сделать - например, сейчас многие разработчики ERP/CRM систем вставляют в них workflow-движки - то в области процессной методологии и специфики управления проектами BPM положение дел совершенно безнадежно. У производителей ERP и их партнеров деятельность заточена под другое. Пересматривать придется все, начиная с типовых договоров и уставов проектов. А это нереально; если даже удастся это сделать, то результат будет настолько не похож на нынешнюю деятельность по внедрению ERP, что сама идентичность проекта как проекта ERP будет утрачена.
В идеальном мире поставщик корпоративной системы должен был бы жестко говорить клиенту: “Наша область - это бизнес-объекты, пользовательские и программные интерфейсы к ним, расчетные алгоритмы и самые примитивные (но за счет этого универсальные) процессные цепочки. И это, поверьте, не мало. Если хотите, чтобы мы качественно сделали эту работу, не грузите нас дополнительно всякой фигней. Нам бы навести порядок в вашей НСИ и вовремя перегрузить данные из того зоопарка, который вы тут развели. Все задачи сверх того - документооборот, сквозные бизнес-процессы, базы знаний - должны решаться другими средствами и в рамках других проектов.”
В реальном мире конечно подобная жесткость неуместна - надо искать компромиссы, но при этом постоянно держать в уме идеальную картинку.
Oracle многие годы декларирует правильные вещи - сначала переход в веб, теперь к SOA - но реализовать получалось не очень. В результате они проигрывают SAP и очень сильно осложнили себе дальнейшую жизнь: ведь многие партнеры, однажды купившиеся на их правильные слова и со свистом пролетевшие, теперь не поверят даже еще более правильным словам.
Да и слова-то, если уж на то пошло, они произносят не самые правильные. Oracle продолжает сидеть на двух стульях: с одной стороны, есть линия ARIS-BPEL, с другой - наследие BEA Aqualogic с идеей “what you model is what you run”. Хотел бы ошибаться, но мне кажется, они отдают предпочтения первому.
MS? Ну, это врядли. Не знаю что должно произойти, чтобы эта компания вдруг стала приверженцев открытости интерфейсов. А без этого смешно говорить о SOA.
SAP, похоже, лучше всех из этой троицы представляет куда надо двигаться. Обнадеживает то, как они развивают сообщество BPX (business process experts). Но развернуть эту махину - софт, шаблоны работы, привычные ожидания партнеров и заказчиков - чудовищно трудно, если вообще возможно.
На Ваш последний комментарий (а именно на абзац с описанием “идеального мира”) надо давать ссылку всем потенциальным и существующим клиентам ERP-внедренцев. Все чертовски верно.
На счет Oracle - они еще по сути ничего не реализовали окромя из СУБД и древнего OeBS (хотя не уверен, что это на 100% их детище). Все остальное куплено. Я помню, как в одном из интервью Эллисона спросили как они собирается интегрировать весь “зоопарк”, который они приобрели за эти годы. Он ответил, что это утопия и в Oracle это понимают, а все приобретения были нацелены не на продукты, а на клиентов и компетенции компаний (Siebel - это лучшее CRM, PeopleSoft - это лучшее HRM и т.д.). Именно их и будут использовать в создании этих Fusion Applications и будущих разработок. Не факт, конечно, что все удастся как это описывается в прессе, но сама идея реальной (а не декларативной) модульности очень воодушевляет.
Чтобы MS стала приверженцем открытых интерфейсов, надо чтобы это стало де-факто стандартом, на котором делают деньги. К сожалению в MBS избрали свой путь - сейчас у них главная идея это “экосистема Dynamics ERP”. Все завязывается на продукты от MS: интеграция с MS SQL RS, AS для построения отчетов (пользуетесь Oracle? извините, работать будет, но делайте все отчеты с нуля и самостоятельно), MS Office (пользуетесь OpenOffice, Lotus? извините, программируйте все с нуля и самостоятельно) и т.д. Но есть и плюсы: движение в .NET, улучшение в AIF (application integration framework). Так что куда пойдет рынок, туда и MS
А вот SAP меня беспокоит больше всего и Вы правильно обрисовали проблему - “махина”. Они стали слишком неповоротливы.
Пётр
Спасибо за содержательное обсуждение.
The comments above mention the possibility of management concepts change within a company. Is it a reality or pure abstraction?
Sandy Kemsly gives the answer in her post from Lean Six Sigma and Process Improvement conference. Citing http://www.column2.com/2010/02/building-a-lean-six-sigma-and-process-excellence-culture/
“Jason Schulist of DTE Energy (a US utility company) gave a presentation on their continuous improvement journey. They’ve been at LSS for more than 10 years, starting with Kaizen in 1998, moving into Six Sigma in 2004, then a performance excellence program more recently.”
I consider this as the argument to my point that the process discipline (BPM) should be separated from management concepts. Instead of embedding a specific concept it should be suitable to implement any concept of company’s choice.