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.

Спасибо за содержательное обсуждение.

На счет 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 меня беспокоит больше всего и Вы правильно обрисовали проблему - “махина”. Они стали слишком неповоротливы.

Мне кажется, автоматизация хаоса в проектах 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. Да, часто это мешает. Но все же иногда и спасает, поскольку клиенты не “заморачиваются” и перед внедрением ERP не производят улучшений на уровне управления бизнеса. А так эта логика позволяет избежать “автоматизированного хаоса”, который мог бы возникнуть (хотя к сожалению и не всегда).

В этом плане интересно будет посмотреть на Oracle Fusion Applications. Это, по-моему, будет первая ERP реализующая SOA в таком объёме (http://soft.compulenta.ru/468265/). А там глядишь и мой MS Dynamics подтянется.

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

И я бы поменял порядок слов на “приводим в порядок элементарные бизнес-процессы”.

Нынешняя беда заключается в том, что с бизнес-процессами пытаются разобраться “заодно” и в проектах ERP, и в проектах Lean/TPS. Но бизнес-процессы не прощают любительского к себе отношения - это самостоятельная дисциплина, требующая вдумчивого отношения. В идеале уровень ERP/функционального управления должен быть реализован так, чтобы он обеспечивал некоторый набор примитивов (регистры - счета, склады, центры затрат и т.п. - и меняющие их состояние хозяйственные операции), которые можно комбинировать на верхних уровнях произвольными способами. Сегодняшние системы устроены по-другому - в них “зашита” определенная концепция. Но движение в направлении SOA, которое декларируют все поставщики, по идее должно привести именно к этому.

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

В этом деле передвижения недвижимости китайцы не первые - большие дома на Тверской переносились еще в 30-х. Или в 50-х? В общем, давно.

Я согласен с тем, что верхний уровень “не проектирует” нижний, но, на мой взгляд, самого верхнего уровня (управленческая концепция) нет. Концепция присутствует и на процессном , и на функциональном уровне (я против того, чтобы рассматривать концепцию как нечто автономное), а “замена” как раз происходит потому что мы меняем концепцию, а “автономность” уровней позволяет нам “не сносить все под основание”, а корректировать\изменять их под новый план. Ведь концепция будет успешной (и даст отдачу) только тогда, когда она “прорастет” в компании повсюду, когда как можно больше сотрудников будут осознавать её ценность. Именно поэтому таких успехов добились Тойота, Моторола - их концепции во многом стали синонимами этих компаний. А в случае необходимости по новому плану можно и дислокацию сменить http://www.xieergai.com/2010/01/movehouse/ =)

Спасибо за комментарий, но Ваше сравнение с планом не готов принять.

Ценность структурирования задачи по уровням абстракции состоит в том, что уровни обращаются друг к другу как к “черным ящикам”. План здания нельзя менять по ходу стройки, а сменить концепцию управления теоретически возможно. Моя идея заключается в том, что какую бы концепцию компания не выбрала, ей не обойтись без компетенции на процессном уровне. В свою очередь, процессный уровень оперирует с бизнес-объектами, реализованными в функциональных системах. Верхний уровень не “проектирует” нижний, он обращается к нему через согласованный интерфейс. Если интерфейс разработан грамотно, то можно заменить нижний, не затронув при этом верхний, или наоборот. SOA в сущности об этом же.

Картинка конечно идеалистическая, но стремиться надо к этому. Компании живут долго, и какой бы замечательный план вы не составили (какую бы концепцию не выбрали), рано или поздно она устареет. Плохо, если единственным выходом в такой ситуации будет пригнать бульдозер - хотелось бы иметь возможность поменять крышу, не снося дом.

Понимание этого приходит с годами, в молодости все стремятся построить дивный новый мир.

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