Файл: Применение процессного подхода для оптимизации бизнес-процессов (Бизнес-процесс: понятие, сущность).pdf

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

Главным результатом детального изучения является построение системного проекта (модели требований), являющегося первой фазой разработки ПОУ (именно фазой анализа требований к системе), на которой требования заказчика уточняются, формализуются и документируются. Системный проект строится на основе модели “как должно быть” и результатов обследования предприятия в части выявления требований к будущей системе.

Фактически на этапе разработки системного проекта дается ответ на вопрос: “Что должна делать будущая система?”. Именно здесь лежит ключ к успешному переходу к ПОУ. В практике, например, автоматизации сложных систем, известно много неудачных реализаций именно из-за неполноты и нечеткости определения системных требований. Системный проект позволяет следующее: описать, “увидеть” и скорректировать будущую систему до^[18] того, как она будет реализована физически, уменьшить затраты на разработку и внедрение системы, оценить разработку по времени и результатам, достичь взаимопонимания между всеми участниками работы (заказчиками, пользователями, разработчиками, программистами и т. д.), улучшить качество разрабатываемой системы.

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

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

Приведем некоторые рекомендации по структурированию моделей деятельности. Во-первых, структурирование должно осуществляться в соответствии с БП предприятия, а не в соответствии с его организационной штатной структурой. Именно БП представляют ценность для клиента, и именно их улучшением необходимо заниматься. Модель, основанная на организационной штатной структуре, может продемонстрировать лишь хаос, царящий в организации, на ее основе возможно внести предложения только об изменении этой структуры. С другой стороны, модель, основанная на БП, содержит в себе^[19] организационно-штатную структуру предприятия. Во-вторых, в моделях должны быть отражены основные виды деятельности предприятия и их взаимосвязи. Например, для автотранспортного предприятия можно выделить следующие деятельности: эксплуатация автотранспорта, ремонт и техническое обслуживание, контроль безопасности, управление производством, обеспечивающая деятельность. Сложные виды деятельности необходимо детализировать. Так “Обеспечивающая деятельность” может включать в себя “Учет кадров”, “Бухгалтерский учет”, “Экономическое планирование”, “Материально-техническое снабжение”, “Складской учет” и т. п. В-третьих, каждая из деятельностей должна быть детализирована на БП. Например, деятельность “Учет кадров” включает в себя БП “Прием на работу”, “Увольнение” и т. д. Дальнейшая детализация БП осуществляется посредством бизнес-функций. Так БП “Прием на работу” содержит в себе функции “Прием заявления”, “Оформление приказа”, “Регистрация” и др.

Построенные модели являются не просто реализацией начальных этапов разработки системы, но и техническим заданием на последующие этапы. Они пред­ставляют собой самостоятельный отделяемый результат, имеющий большое практическое значение. В частности, модель “как есть” включает в себя существующие неавтоматизированные технологии на предприятии. Формальный анализ этой модели позволит выявить узкие места в БП и предложить рекомендации по их улучшению (независимо от того, предполагается на данном этапе переход к ПОУ или нет). Модели позволяют осуществлять автоматизированное и быстрое обучение новых работников конкретному направлению деятельности предприятия (так как ее технология содержится в модели) с использованием диаграмм (известно, что “одна картинка стоит тысячи слов”). С помощью моделей можно осуществлять предварительное рассмотрение^[20] нового направления деятельности с целью выявления новых потоков данных, взаимо­действующих подсистем и БП.

Системный проект полностью независим и отделяем от конкретных разработчиков, не требует сопровождения его создателями и может быть безболезненно передан другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации проекта, он может быть “положен на полку” до тех пор, пока в нем не возникнет необходимость.

После выбора системного проекта на основе выявленных и согласованных требований осуществляется разработка следующих предложений: составление перечня автоматизированных рабочих мест предприятия и способов взаимодействия между ними, анализ применимости существующих систем управления для решения требуемых задач и формирование рекомендаций по выбору таких систем, принятие решения о выбо­ре конкретной (существующей) КИС или разработке собственной системы, разработка требований к техническим средствам, разработка требований к программным средствам, разработка предложений по этапам и срокам перехода к ПОУ.

На следующем этапе (проектирования) на основании принятых решений по переходу к ПОУ осуществляется преобразование системного проекта в техничес­кий проект (модель реализации). На этапе проектирования вырабатываются пути реализации моделей требований, которые порождены и зафиксированы при анализе. На этом этапе осуществляется построение модели реализации (или физической модели), демонстрирующей, как система будет удовлетворять предъявленным к ней требованиям (без технических подробностей). Здесь определяются параметры реализации на уровне типов. Зная типы подсистем и потенциальную аппаратную платформу, можно приступать к поиску коммерческих пакетов, которые удовлетворяют требованиям, выявленным и зафиксированным на этапе системного проектирования. ^[21]

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

Отметим недостатки разработки собственной КИС по сравнению с покупкой готовой системы. Трудозатраты на создание собственной КИС огромны и составляют сотни и тысячи человеко-лет, стоимость разработки соизмерима со стоимостью готовой системы (а часто значительно превышает ее). Использование готовой системы менее рискованно, чем разработка собствен­ной. Готовая система внедряется поэтапно и поэтому частично может быть доступна в рабочем режиме гораздо быстрее, чем собственная. ^[22]

7. Что ожидают руководители организаций от внедрения процессного подхода?

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

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

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

1. снижение издержек;
2. повышение рентабельности;
3. повышение управляемости (улучшение системы отчетности компании, создание прозрачной системы управления, ускорение процедур принятия управленческих решений);
4. снижение влияния человеческого фактора при управлении компанией. ^[23]

Вариант 3. Под действием рекламы консалтинговых компаний собственники, менеджеры или специалисты организации пытаются найти оптимальный программный продукт для управления предприятием. Обычно эти поиски ведутся со следующей подспудной мыслью: «Мы найдем программу, опишем бизнес-процессы, введем их в компьютер, затем нажмем кнопку «Enter» и тогда компьютер:

а) скажет нам, где у нас плохо и как это нужно оптимизировать;

б) будет оптимально управлять предприятием вместо нас».

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

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

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