---

Comments

«5 копеек». Наличие перечня типовых бизнес-процессов в ключевых отраслях, где внедрена некотораясистема, ровным счетом ничего не дает для ускорения внедрения – разве что консультанту, «плавающему» в моделируемой/автоматизированной предметной области, позволит хоть как-то что-то где-то. Ну вот взять кредитование – какая должна быть референтная модель, чтобы учитывать наличие у банка «зоопарка» ОДБ (АБС), их архитектуру, учетную политику и т.д. и т.п? Ответ – или очень поверхностной, или очень подробной, и на практике – чаще всего первый вариант, с которого толку то

---

Чтобы быть по-настоящему полезной, референтная модель должна включать в себя не только бизнес-процессы, но и информационные объекты, описывающие структуры данных, которые передаются от одного шага процесса к другому в ходе выполнения определенных, в рамках предметной области, задач. Объекты должны быть представлены на таком уровне абстракции, который не зависит от их реализации в той или иной информационной системе. При таком подходе, стыковка бизнес-процесса в BPMS с ИТ-ландшафтом осуществляется через интерфейсы, структура которых (со стороны BPMS) соответствует информационным объектам референтной модели. Внешняя часть интерфейса может иметь другую структуру, соответствующую представлению передаваемой информации в исходной или целевой системе. Связь между внешней и внутренней частями обеспечивается с помощью механизмов мэппинга, которые являются неотъемлемым компонентом любой промышленной BPMS, в том числе, webMethod и SAP ХI.         

---

Добрый день Александр!

Тут можно поспорить! 

Во-первых, присутствие готового типового бизнес-процесса (решения) в BPM - системе уменьшает затраты на пилот, который, как правило, требуется покупателем при принятии решения о внедрении информационной системы. Можно быстро показать Клиенту именно его бизнес-процесс, а не абстрактные возможности BPMs. 

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

Возможно я не уточнил, что под процессом в BPMS я имел в виду не только логику, но и формы, структуру хранения и т.д.  В общем прототип, с учетом полной функциональности. Соглашусь, что от одной модели процесса из 20-30 шагов толку будет не очень много!

---

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

Однако, несмотря на обсуждение - перечень решений пока не расширили :). Так где же еще можно использовать BPMs?

---

В данный список можно добавить:

- госсектор (предоставление гос. услуг в электронном виде)

- любое управление заявками, вне зависимости от отрасли

- управление инцидентами (например, в телекоме)

 

---

Конечно, шаблоны типовых процессов необходимы. У некоторых поставщиков речь идёт даже о референтных моделях организации различных секторов экономики.
Что касается списка процессов, думаю, можно отталкиваться от процессов предопределённых в отраслевых стандартах. Например, ISO9000 - как основа, из него, ISO20000 для IT-services и т.д.
 

---

Добрый день Андрей!

Есть определенные возможности у BPM систем, и это дает некоторое ограничение по списку процессов. Например для процессов планирования производства, бюджетирования и закупок применение BPMs не всегда эффективно, поскольку автоматизации планово-учетной модели тут важнее, чем автоматизация потока работ - workflow.

Но есть процессы, где BPMs является ключевым компонентом, именно их список мы и пытаемся сформировать. В ISO 20 000  это могут быть процессы: управления инцидентами и проблемами, управления изменениями. Тогда как процесс управления конфигурацией должн быть автоматизирован на основе учетного решения.

В отраслевом стандарте eTOM зафиксированы "сквозные" процессы  - подключение абонента и обработка инцидента сети - это как раз для BPMs.

---

Вообще, референтные модели могут нести в себе не только отраслевую, но и функциональную специфику. В качестве примера могу привести процессы бизнес-планирования и бюджетирования, которые: a) представляют собой отдельную функциональную область; b) являются сквозным финансовым отражением всех аспектов деятельности предприятия. С другой стороны, существует отраслевая специфика данных процессов: бюджетирование компаний, оперирующих в сфере розничной торговли, значительно отличается  от бюджетирования добывающих или производственных предприятий.

Важно отметить, что реализация описанных процессов, как правило, требует использования BPMS, в связи с необходимостью организации обмена данными с разными типами систем (ERP, SCM, MES, ...), файловыми источниками, БД НСИ, формами ручного ввода и т.д., в зависимости от специфики ИТ-ландшафта.     

---

Антон, здравствуйте! ИМХО, информационные объекты, описанные с той степенью абстракции, когда они не зависят от конкретной системы, при этом привязанные к обобщенным процессам, пригодны по стольку поскольку. Конечно, если внедрение BPMS идет по сценарию «подгонка процессов под систему», то, это, безусловно, очень облегчает жизнь внедренцу. Но польза для клиента… ИМХО, есть сомнения, поскольку природа появления референтных моделей (у всех вендоров) хорошо известна – это устаревшие, порезанные, упрощенные модели старых клиентов, при этом их применение для бизнес-процессов не только сомнительно, но и рискованно с точки зрения бизнеса. Для обеспечивающих процессов – однозначно да, референтные решения полезны, но ведь в приведенном перечне нет ни одного обеспечивающего! Безусловно, рассуждать о качестве моделей, которыми, располагает Ваша компания, с моей стороны будет просто не корректным – я их не видел, но, поскольку за время с момента слияния IDS и SAG я также не видел ни одного пресс-релиза на сайте Вашей компании о внедрении WebMethodв России и СНГ, то, очевидно, что это «западные» модели – и подходят ли они к нашим реалиям, это даже не вопрос. 

---

Андрей, добрый день!

Во-первых, присутствие готового типового бизнес-процесса (решения) в BPM - системе уменьшает затраты на пилот, который, как правило, требуется покупателем при принятии решения о внедрении информационной системы. Можно быстро показать Клиенту именно его бизнес-процесс, а не абстрактные возможности BPMs. 

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

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

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

---

Здравствуйте Александр. Говорить о корректности или некорректности рассуждений можно в рамках общего контекста, а у нас с вами не то чтобы контекст разный, но уровень детализации сильно отличается. Когда я говорю об информационных объектах, у меня картинка совершенно четкая перед глазами. Есть контрагент, у него набор атрибутов: название, юридический адрес, телефон, факс, ИНН, КПП и т.д.. Как, и с какой полнотой атрибуты представлены в той или иной системе абсолютно неважно. Переложить из внутреннего представления в референтное проблемы не составляет. Что касается неактуальности и упрощенности моделей - модель структурирует накопленный опыт и должна развиваться по мере получения новой информации, она не должна быть статичной. Модель это инструмент а не памятник в граните.    

---

Сколько людей, столько мнений.

Что касается пилота, то тут не все так просто - клиент за него не платит, при этом могут выбрать и другую систему - что приведет к прямым затратам. Можно сделать несколько пилотов и лишь один приведет к продаже. Это нужно учитывать.

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

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

Не буду Вас уговаривать!

Мы уже идем от готовых прототипов, и это дает положительные результаты. Сейчас мы уже сделили  прототип на системе  webMethods для процесса Комплексная государственная услуга "Регистрация рождения ребенка ". Также в разработке еще несколько государственных услуг. Да и банки со страхованием нами не забыты.

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

Хорошая дискуссия получилась для пятницы!

Всем хорошего отдыха!

---

Коллеги, выскажу и свое мнение, несмотря на выходные и формальное завершение обсуждения топикстартером :)

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

С процессами все немного сложнее, их автоматизация гораздо моложе и требований к стандартизации здесь гораздо меньше. Даже известные нам стандарты в области менеджмента качества описывают требвания к тем или иным процедурам с минимальной степенью детализации, оставляя за организацией право варьировать в конкретной реализации этих требований. И, как правило, референтные модели здесь тоже выстраиваются на достаточно высоком уровне абстракции - тот или иной тип процесса должен содержать в себе такие-то этапы. Реализация же конкретного операционного процесса может быть очень разной в различных организациях. И я верю, что эта конкретная реализация может давать организации конкурентные преимущества. Не случайно одной из полезнейших характеристик процессного подхода к управлению называют Agility - гибкость, позволяющую быстро перестроить операционную деятельность в ответ на изменившиеся внешние условия. Невзирая на наличие якобы "лучших практик" и "референтных моделей".

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

То есть, референтные модели бизнес-процессов - возможны и полезны как отправная точка описания, но ни в коем случае не являются "памятником в граните", по меткому выражению Антона. Иное дело - процессы органов госвласти, например, в области предоставления госуслуг. Здесь все четко регламентировано Законом, и единожды созданное решение действительно может быть референтным и тиражируемым на все субъекты. Чем мы сейчас и занимаемся понемногу.

---

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

---

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

---

Конечно, я имею в виду не объекты материального мира, а их отражения в ИС. И я продолжаю утверждать, что референтные модели объектов - это явление нормальное, полезное и зачастую обязательное, а вот по процессам такая практика пока не сформирована, во всяком случае, на детальном, операционном уровне.

+1

---

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

---

Александр, коллеги, посмотрите мою статью про типовое решение для бюджетирования - http://www.ariscommunity.com/users/achekhov/2010-08-28. Я попытался несколько шире взглянуть на проблему тиражирования проектного опыта и дополнил референтные модели сопутствующими элементами, формирующими, в совокупности, инфраструктуру быстрого прототипирования и внедрения системы.

---

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

Маленькая ремарка. В моем понимании, для бизнес-процессов (которые часто называют основными) качественная референтная модель не возможна или маловероятна, по той причине, что эти процессы есть суть каждого отдельного (т.е. уникального) бизнеса. Для остальных процессов (которые кто как хочет, так и называет – от обеспечивающих, до управляющих), к которым относятся и процессы бюджетирования, референтная модель возможна и полезна, поскольку эти процессы влияют на эффективность бизнеса, но не на его суть.    

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

---

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

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

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

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

---

Отклоняясь от вопроса "Где нужны BPM-системы?", так как дискуссия развернулась вокруг типовых процессов, хотелось бы отметить. Имея не большой опыт в формализации процессов гос.учреждения, убеждён, что референтные модели могут нести в себе и индивидуальную специфику. Даже при такой "радикальной" зависимости от законодательства, от организации к организации, процессы, в исполнительском смысле, формируются совершенно разные. При описании операционных процессов всё зависит от структуры (иерархии) организации. Еще более значимые различия наблюдаются при описание стратегических процессов, несмотря на узкие рамки заданные законом, организации умудряются удержать линию личной стратегии, что приводит к абсолютной неустойчивости референтных моделей. Явственным это стает при рецензии и анализе того или иного процесса. Резюмируя этот опыт приходишь к выводу, то что референтные процессы целесообразны только для поверхностного понятия и ориентации, что по моему мнению отнюдь немаловажно и эффективно. Однако, думаю, что у многих клиентов эйфорическое понятие о типовом процессе (Best Practice), тем более если он от именитой организации и был успешно внедрён. Это заблуждение приведёт в лучшем случае к лишним затратам...

---

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

Но, как совершенно верно Вы отметили, для стратегических процессов не подходит такой подход, он помогает только для операционной регулярной деятельности с большим числом участников (операционный уровень). 

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

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

---

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

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

---

Александр, вы смешиваете понятия. Процесс ковыряния в носу управляем, а значимый результат отсутствует. Управление подразумевает цель. Цель бизнеса (в общем случае) - максимальная прибыль при минимальных затратах. Оптимизация процесса ведет к сокращению затрат.

Я не вполне согласен с Андреем, который разделяет стратегические и оперативные процессы в контексте оптимизации через упрощение. Стратегические процессы можно и нужно оптимизировать, например, необходимо уменьшать объем и разнообразие информации для принятия решений (то есть, упрощать процесс). Технологии оптимизации известны: статистические фильтры, ограниченные наборы KPI, OLAP и др. Некоторые из этих технологий могут тиражироваться в составе референтных моделей, в частности, система ключевых показателей с отраслевой или функциональной спецификой.           

---

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

Что касается вашего поэтического примера с ковырянием в носу, то многие медики как раз считают, что этот процесс не управляем, это психическая патология :) Ну и результат соответствующий :)

---

С пятницей Вас дорогие коллеги! Обсуждение продолжается с новой силой!
Только суть вопроса куда-то сместилась, в сторону теории построения процессов.
Вот цитата из википедии:

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

Онтологии используются в процессе программирования как форма представления знаний о реальном мире или его части. Основные сферы применения — моделирование бизнес-процессов, семантическая паутина (Semantic Web), искусственный интеллект.
 

Так вот, как я понимаю, вопрос состоит в том, нужны ли BPM-сообществу онтологические модели организаций и их процессов? Есть ли от них польза? Кто, когда и как их будет делать? Возможно ли их совместное использование сообществом и в каком виде?

Если неправ - поправьте меня...

---

Александр, давайте попроще, а то мы куда-то уж совсем в дебри погружаемся - теряю нить ваших рассуждений. Как говорится: "Усложнить легко, упростить сложно".

Приведу простую аналогию. Мастера, которые делали развал-схождение, забыли на левой рулевой тяге моего автомобиля разводной ключ. Этот, не предусмотренный конструкцией, гаечный ключ снижал результативность процесса управления в части левого поворота (иначе говоря, мешал повернуть колеса на предельный угол). Изъятие ключа (упрощение конструкции) привело: a) к оптимизации процесса; b) возвращению его в стабильное состояние.

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

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

---

От темы нас унесло, ну да ладно! Пятница.....

1. Про простоту! Чем меньше людей участвуют в процессе, там лучше - это вроде от классиков :). А про конкурентные преимущества "скрытые" в маршрутизации работ по компании - в это я не верю. Конкурентные преимущества скрыты в бизнес-модели и в качестве работы сотрудников!!! Так что процессы/workflow нужно упрощать и ускорять, без ущерба качеству!!!

2. Про госсектор!! Схема "госсектор-процессы-улучшение жизни граждан" сейчас не работает - спорить не буду, но к ней нужно стремиться!! Иначе не имеет смысла ни  автоматизировать, ни оптимизировать процессы госслужбы.

3. Про онтологические модели!!! -  куда без них - это уже целый рынок инструментов и компаний - без них уже нельзя :)

---

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

Поэтому устранение ключа – это обработка исключений, но ни как не оптимизация ни процесса СТО, ни процесса вождения. Хотя наши с вами реалии как раз таковы – проще устранить следствие, чем причину.

Что касается госсектора. Позвольте, но изъятие из процесса согласования чиновника-коррупционера не то что выведет систему из стабильного состояния, оно ее взорвет :) Ну конечно, если только заказчиком «оптимизации» не является сам этот чиновник. Это ж какие схемы рушатся, кто ж это так просто отдаст поломать! Я могу только представить, как это «не выводит систему из стабильного состояния» :)

А стрелять… никогда это не помогало, а делало только хуже. И опять таки подход – устранение следствия (чиновника), а не причины – системы.

---

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

---