Let me give an advice for companies who have both a desire and resources to improve.
Many of the leaders that I meet are overwhelmed by a huge number of available concepts, strategies and recipes to improve their business. Look at the Wikipedia page outlining modern business strategies to get the idea of choise problem they face. Which one is the best, which will return the most on invested dollar - Toyota Production System? Business Process Management? ERP? CRM? Balanced Scorecard? or may be one of dozens of other alternatives?
Yet the number of options is only part of the problem, another one is absence of a framework to fit these concepts and methodologies into. Management gurus typically don’t care to define the scope precisely neither to consider interfaces with related disciplines. Everyone sells his recipe as a comprehensive and only worthy of attention.
Where does it lead?
- Buridan’s ass syndrome: a leader inclined to perfectionism doesn’t take anything because he is unable to make an optimal choice.
- Silver bullet syndrome: a leader inclined to adventures accepts the first theory which hooked him and which he can afford. BTW, this is generally not a bad strategy: apply more leadership and common sense, less bigotry - and almost every theory will lead to success.
For comparison let’s look at the related area of business software and IT consulting.
They provide enough ground for cricism; their promises should be divided by 4 (or even 16) but there is a significant difference: information technologies are structured. There is so-called stack of information technologies which looks like this:
Each stack level offers a number of alternatives and competing suppliers to choose from. But we do not choose between say a cable network and CRM system. It would be foolish to opt for CRM because this is what provides a real value for a salesman while the average user does not care about the network cables and switches.
But this is what happens when business and management concepts are considered! Hence I believe it’d be usefull to introduce a notion of Management Competencies Stack. (I use term “competency” rather than “technology” because business and management are more humanitarian than IT.) Here it is:
Some examples:
- customer relationship management, manufacturing planning, budgeting belong to functional management level (they relates to sales, production and finance respectively)
- BPM belongs to the process management level (not to be confused with BPMS which belongs to the middleware level of IT stack)
- Toyota System, Lean, Six Sigma and Theory of Constraints belong to the concepts level
The relationship between the levels here is the same as in IT: the bottom level without the top lacks the target while the top level without bottom lacks supporting technologies.
- Looking top-down, the bottom level is an enabler for the top. This is a gear connecting abstract ideas to specific activities performed by specific people.
- Looking bottom-up, the upper level is what gives a purpose to the activities of the lower level and multiply their impact.
Few examples to illustrate these relationships:
- An ordinary company can’t exist without competencies in sales, production or services (functional level).
- A company which has grown to certain size and level of maturity should put efforts to coordinate activities of functional units within an end-to-end business processes or projects (the process and project management level). Otherwise functional units increasingly work for themselves rather than on the client.
- The value chain theory (concepts level) specifies the purpose for business process initiatives (the process and project management level). Such initiative shouldn’t be only about doing things right, but also about doing the right things.
- Theory of constraints (concepts level) defines a procedure (”five steps”) which helps to pick the most promising business process for your process initiative i.e. the one which will maximise return. Business process initiatives lacking connection to the concepts level come down e.g. to analysis of six levels process hierarchy - a sound excercise indeed but not well rewarded in terms of company’s bottomline.
A lower level of the competence stack is the enabler for upper levels. But does upper levels skills have value in the absence of the lower?
I think yes, yet limited:
- If you try to implement process management in the absence of accounting then your achievements will be limited (if any): you’ll quickly find out that every business process operates with business objects managed by enterprise databases and applications. For example, if you target the “inquiry to order” process without a CRM system then after a while you will find yourself developing your own CRM within the BPM project. (It maybe justified in some cases but be aware that packaged CRM applications will likely be superiour to in-house development.) BPM is mostly for those who have ERP and CRM but aren’t happy with these.
- Lean implementation without competence in process management may be successfull at departmental level but it’ll be hard to extend this methodology to the enterprise level because BPM is the key competency in dealing with cross-functional business processes.
Conclusion: starting from top-level competency may only make sence to gain initial education and experience. Their full power is unleashed only when supporting competencies are presented at the lower level.
Unfortunately the existence of different levels of management competencies and relationship between them is not realized by managers and consultants. I guess this is the background of some dramatic failures.
A likely scenario:
- Assume that Company A has made impressive progress in transforming its business. The information about this success become public.
- Consultants participated in A’s project wrapped up the experience into a new methodology X and started to promote agressively the X and themselves. This is how TQM (Xerox), Lean (Toyota), Six Sigma (Motorola) were invented.
- Company Q decided to use the X methodology and repeat A’s success. Yet the books about X tell little about the necessary Y and Z competencies - mostly because Y and Z are taken for granted at A. Besides, any pre-conditions would have negative impact on sales of X-based services.
- As a result the Q’s project fails. A succeeded and Q failed because A posessed necessary low-level competencies while Q decided not to waste time and take the shortest route to “success”.
Failure to understand the relations between competence levels also leads to wrong assesment of investments effectiveness. For example, it’s widely known BPM projects compare favorably to ERP in terms of ROI. Given that ERP belong to functional competence and BPM belongs to the higher level of process competence, it is not surprising. ERP implementation gives some immediate effect but probably more important is that without ERP you can not benefit from BPM and other skills of the upper levels. Similarly, you can not effectively implement Lean without BPM.
Summing up, here are the promised advices:
- Do not approach full-scale implementation of upper level competency before mastering the lower-level competencies it depends on - the return will not match the expectations.
- Don’t stop after implementing a low-level competency - the most part of the reward comes from implementing top-level competencies that become accessible.
Single-move thinking isn’t enough in business - sometimes you need to plan combinations like in chess. Consider not only material gains (current income) but also the position in the play (acquisition of basic competencies) and the tempo (business agility).
This game isn’t for short-thinking minds indeed. There is also a risk that your successor will harvest after your combination.
Explaining such a combination to shareholders is another tough task. Yet I hope that proposed competense stack is simple yet helpfull for this task.
But probably the toughest question is - what to do if the company has came to the edge already? Well, “Only the paranoid survive.” For others it’s always too early to think forward until suddenly it becomes too late.
If you suddenly found yourself in a swamp fighting with crocodiles you have to think both about the nearest crocodile and draining the swamp.
The following posts consider various aspects of the management competence stack:
Рад, что “набрёл” на Ваш блог. Я занимаюсь внедрением 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.