Проектирование бизнес-процессов
Традиционный подход предполагает описание некоего состояния «как было», поиска узких мест и внесения поправок в систему, которую после этого можно квалифицировать, как «исправленное «что было». Простой и эффективный прием для не совсем запущенных случаев. Однако отсутствие ориентации на то, «что нужно» - серьезный недостаток такого подхода, особенно, когда текущая цель собственника находится далеко в стороне от того, что делает предприятие. Добиться верной направленности позволяет разработка и формализация стратегии. Пример стратегии формализованной с помощью стратегической карты – рисунок №. 1
Рисунок 1. Пример стратегической карты предприятия ИТ-отрасли
Построение карты начинается с выяснения цели собственника. Что он ждет от своего предприятия? В приведенном примере цель проста и понятна – увеличение стоимости бизнеса на долгосрочном горизонте событий и рост прибыли в ближайшей перспективе. Возможны и другие цели – увеличение инвестиционной привлекательности, например. Главное условие – достижимость цели, ее четкое и ясное определение (например: «хочу иметь возможность через три года продать данный бизнес за 10 миллионов»). Как правило, постановка цели производится в диалоге собственника с бизнес-аналитиками и топ-менеджерами компании, чья задача довести не очень четкие пожелания до конкретных цифр и фактов, которых желательно достигнуть за некоторый промежуток времени. На этих же совещаниях намечаются и способы достижения главной цели. В нашем примере высшую цель – повышение стоимости бренда – можно разделить на две подцели – высокая стоимость бренда компании и брендов продуктов компании – так решили аналитики, изучая деятельность предприятия. На нижних уровнях показано, за счет чего можно повысить эти ценности. Получившаяся в итоге карта четко выделяет основные направления, в которых следует действовать для достижения главной цели, указанной собственником.
И вот уже теперь можно действовать по приведенному выше шаблону. Стратегическая карта показывает, каких подцелей нужно добиваться для достижения высшей цели. Имея этот ориентир, цепочка «как было» - «как будет» обретает смысл и нацеливает проектирование системы управления на решение стратегической задачи. Каждый элемент имеющейся системы управления может иметь или не иметь влияние на достижение какой-либо из целей стратегической карты. Понятно, что реинжиниринг требуется только для важных для достижения стратегической цели элементов.
Какие элементы подвергаются анализу? В первую очередь, ассортимент предлагаемых компанией товаров и услуг. Составляется реестр – полный пакет этих предложений – и производится его анализ. Все ли из того, что мы производим, выгодно, полезно и способствует достижению основных целей? Стоит ли расширить наш ассортимент? Нужно ли сократить его в части невыгодных товаров или услуг? Можно ли невыгодные товары или услуги сделать выгодными (а выгодные – супер-прибыльными?). Составляется перспективный пакет продуктов и услуг, для которого и будет производиться моделирование бизнес-процессов. Для продуктового анализа можно, например, использовать матрицуBoston Consulting Group (рисунок 2).
Рисунок 2. Матрица Boston Consulting Group. В применении к теме статьи проектирование бизнес-процессов наиболее актуально для «звезд» (в том числе потенциальных) и «дойных коров».
Проводить анализ «как есть» в отношении бизнес-процессов требуется далеко не всегда. Грамотные бизнес-аналитики (или опытные руководители) обычно в состоянии предложить бизнес-процессы в варианте «как надо». Однако, встречаются ситуации, когда «как надо» не в состоянии сказать никто – например, абсолютно новый вид бизнеса или предприятие с большим количеством сложных взаимодействий между подразделениями, нуждающееся в повышении эффективности своей работы. Оптимизировать его работу возможно лишь путем скрупулезного анализа действующих бизнес-процессов. При этом весьма вероятно, что анализ покажет – интуитивно выстроенные связи и взаимодействия являются оптимальными, и повышение эффективности следует искать в других местах. Тем не менее, построение действующей схемы бизнес-процессов будет полезным для предприятия – поскольку предоставляет возможности к формализации деятельности, а также готовит почву для работы в случае каких-либо изменений в бизнесе.
К особенностям проектирования системы управления новым, только создаваемым предприятием следует отнести отсутствие анализа того, «как было». Система управления изначально проектируется для достижения стратегических целей предприятия.
Команда участников
«Кадры решают все!». Этот лозунг, как нигде актуален в процессе совершенствования системы управления. Для решения этой задачи невозможно просто нанять профессиональных исполнителей, которые сделают все за вас. Заинтересованное участие ключевых сотрудников компании является непреложным условием решения этой задачи. С другой стороны, приглашение сторонних профессионалов хотя и желательно, но необязательно – если свои сотрудники берутся за выполнение всех необходимых функций. Попробуем описать эти функции и набрать формальную команду исполнителей, а также указать важность профессиональных навыков для каждого.
Стратег. Он же Руководитель проекта. Задача этого человека в проекте – воплощать ожидания собственника в стратегию их достижения, координировать действия остальных участников, решать конфликты в тех случаях, когда требуется видение ситуации целиком. Стратег, если применять военные ассоциации, должен представлять картину сражения в целом – то есть, должны выполняться оборонительные действия. На одних участках – наступательные, на других – конница в определенный момент должна выскочить из засады для обеспечения прорыва, танки воспользоваться этим прорывам для прорыва в тыл и разгрома противника… Его не волнует, каким строем будут двигаться танки – это местная тактическая задача. Его не волнует, какой транспорт будет использован для подвоза боеприпасов – их просто должны доставить в нужном количестве. В то же время, если отдел снабжения и командир танковой бригады не смогут договориться о количестве и сроках подвоза снарядов, стратег, зная общую логику работы системы, должен разрешить конфликт между службами, руководствуясь своим мнением о необходимом балансе. Одна из наиболее реальных кандидатур на выполнение этой функции – генеральный директор (впрочем, бывает и так, что генеральный директор является «свадебным генералом», либо слишком занят и может доверить функцию стратега заместителю или внешнему консультанту). В зависимости от опыта, загруженности, наличия специальных знаний, в помощь ему могут привлекаться как заместители, так и внешние консультанты (например, руководитель или координатор проекта со стороны исполнителя). Однако принятие окончательных решений остается все-таки именно за этим единственным человеком, либо иногда за собственником предприятия.
Бизнес-аналитики. Опытные консультанты в части стратегии и бизнес-процессов, владеющие навыками их проектирования, анализа и оптимизации. Предпочтительно для выполнения этих функций приглашать профессионалов, получивших специальное образование и имеющих опыт реальных и успешных проектов. Однако, применяя существующие рекомендации общего плана и собственный здравый смысл, топ-менеджеры предприятия способны выполнять эти функции, как минимум, на среднем уровне. Ведь, по сути, финансовый директор, главный инженер, зам по развитию и другие руководители по долгу службы обязаны уметь анализировать стратегические и тактические аспекты своей деятельности. Профессионального бизнес-аналитика отличает от них разве что опыт работы на других предприятиях, способность выйти за рамки привычных представлений и знание рекомендаций, заведомо приносящих положительный результат. Как пример подобных рекомендаций можно привести: распараллеливание процесса там, где это возможно, применение автоматизации, минимизацию числа бизнес-процессов, выполняемых разными подразделениями.
Проектировщики бизнес-процессов нижнего уровня. Для того, чтобы понять – кто эти люди, рассмотрим задачу с точки зрения стоящей задачи. Для небольшого предприятия, как правило, выделяются 7-8 бизнес-процессов верхнего уровня (например, производство продукции, продажи, снабжение, воспроизводство персонала, и т.п.). Каждый из них делится еще на 7-8 подпроцессов помельче – более детальных (так, «производство продукции» может включать в себя производство деталей, сборка изделий, контроль качества) – то есть, в итоге имеем около полусотни бизнес-процессов. В крупных компаниях, как правило, необходимо дальнейшее деление – еще на один или два уровня. (Рисунок 3)
Рисунок 3. Пример деления бизнес-процессов среднего предприятия. Для крупных – просто добавьте один-два этажа вниз…
Пример – единственный менеджер по кадрам средней компании осуществляет свою функцию в рамках единственного бизнес-процесса, который называется просто «подбор персонала». Учитывая, что практически всю работу он выполняет самостоятельно, никакого регламента для этой работы писать не требуется. Другое дело – отдел кадров крупной компании, где существует разделение различных функций между сотрудниками. Процесс «подбор персонала» в таком случае складывается уже из десятков более простых действий, выполняемых различными людьми – и вот их взаимодействие и требуется описать бизнес-процессами нижнего уровня. Конечным уровнем для деления бизнес-процессов является бизнес-операция – процесс, полностью выполняемый и контролируемый одной кадровой единицей. И для очень крупных компаний вполне реальны тысячи бизнес-процессов. Теперь сделаем воображаемую проекцию картины бизнес-процессов на схему подразделений предприятия. Очевидно, что некоторые бизнес-процессы будут полностью укладываться в рамках одного подразделения. Будут также и процессы, за выполнение которых отвечает (в той или иной степени) два и более подразделения. И самые неприятные ситуации, это те, в которых ответственность за выполнение бизнес-процесса неоднократно переходит от одного подразделения к другому (забегая вперед, скажем, что таких бизнес-процессов рекомендуется, по возможности, избегать). На рисунке 4 схематично показаны бизнес-процессы условного предприятия по производству продукции. Часть бизнес-процессов, показанная черными стрелками – протекает внутри подразделений. Другая часть – синие стрелки – переходит из одного подразделения в другое. И, наконец, третья часть – процесс, в котором задействовано несколько подразделений. Красный пунктир.
Рис. 4. Принадлежность бизнес-процессов. Черными стрелками обозначено протекание внутренних бизнес-процессов подразделений, цветными – процессов более высокого уровня.
Кому лучше всего доверить моделирование бизнес-процесса нижнего уровня, за который полностью (или почти полностью) отвечает одно подразделение? (Кому доверить построение танкового отряда для выполнения прорыва?) Ответ напрашивается сам собой – это руководитель подразделения (либо внешний консультант такого уровня, работающий с руководителем подразделения). А вот планировать взаимодействие конников, танкистов и снабженцев доверить руководителю одного из этих подразделений было бы, по крайней мере, опрометчиво – слишком велик риск «перетягивания одеяла на себя». Поэтому моделирование бизнес-процессов верхних уровней, процессов с большим числом взаимосвязей между цехами и отделами должен проводить непосредственно стратег, как лицо, заинтересованное в успехе всего предприятия, а не отдельного подразделения. Минимальные требования к проектировщикам совпадают с должностными обязанностями названных сотрудников. Найм сторонних специалистов может частично разгрузить руководителей, а большой опыт и профессиональные навыки – ускорить работу.
Исполнители. Они же – эксперты по бизнес-процессам нижнего уровня и… подопытные кролики. Мало составить теоретически верную схему взаимодействия. Для победы нужно реализовать ее на практике. То есть довести до рядовых исполнителей и добиться ее исполнения. Идеальный вариант – это выделить из ряда сотрудников, выполняющих одинаковую работу, одного-двух наиболее активных и способных и доверить им работать по-новому – до того момента, пока система не будет отлажена. Другой вариант – постепенный переход от части старых процессов к новым, их заменяющим. Однако в реальности такое получается далеко не всегда. Система отношений (особенно, если она не была оптимизирована) может оказаться настолько сложной, что в тестирование придется вовлекать большое количество участников. Некоторую аналогию можно провести с примером внедрения автоматизированной информационной системы. Редко когда удается замещать отдельные участки старой системы новыми решениями. Гораздо чаще сотрудникам приходится некоторое время вести учет параллельно в старой и новой системах. Для этих участников команды найм сторонних исполнителей невозможен. Однако, внешние консультанты могут существенно ускорить внедрение, выделив профессионалов для обучения и консультаций сотрудников предприятия и наблюдения за правильностью выполнения процессов.
Вопрос: Может ли команда, сформированная только из сотрудников предприятия, не привлекая внешних специалистов, пользуясь некими методиками и здравым смыслом, построить и внедрить новую систему управления – от Стратегической карты до детальных бизнес-процессов, регламентов и т.п.?
Ответ: Четких методик правильного построения бизнес-процессов «от и до» не существует, но есть рекомендации, а также референтные модели. На их основе, используя свой и чужой опыт, сильный управленец способен, как минимум, выстроить действующую систему. Однако, для того, чтобы выжать из системы максимум эффективности, помимо большого (и, желательно, широкого) опыта, нужна изрядная часть таланта. В таком случае предприятие имеет реальный шанс «войти в десятку». Для того же, чтобы стать безусловным лидером в своем бизнесе, предприятию потребуется помощь гениальной команды во главе с соответствующим лидером.
Собственно проектирование…
Как уже сказано раньше, единственной методики разработки бизнес-процессов не существует. В этом разделе попробуем рассмотреть ряд ключевых моментов, на каких следует сосредоточиться, а какие – оставить за бортом своего внимания.
Полнота и гармоничность бизнес-процессов верхних уровней. Важность этого критерия равноценна важности собственно бизнеса. Полководец должен выиграть сражение сначала в своем уме, представив, как должны развиваться события на поле боя – иначе не стоит даже и приближаться к врагу. В зависимости от размера компании, два-три уровня нужно проверить на целостность и органичность.
Концентрация усилий на выполнение стратегических целей. Бизнес-процессы, не имеющие влияния на ключевые показатели, разрабатываются в последнюю очередь, либо не разрабатываются вообще. Проведем простейший расчет: для предприятия, имеющего три уровня бизнес-процессов (то есть не очень большое унитарное предприятие) мы имеем 7-8 процессов верхнего уровня, каждый из которых делится на 7-8 БП второго уровня, такой же принцип деления сохраняется и ниже. Как результат, уже на третьем уровне имеем более 350 бизнес-процессов. В среднем, каждый бизнес-процесс состоит из десятка операций, что дает четыре тысячи операций в целом для предприятия. И это только для небольшого! Геометрическую прогрессию до четвертого и пятого уровня предлагаю посчитать самостоятельно. Конечно, пятого уровня детализации требуют только такие монстры, как Газпром или РАО ЕЭС – но и для четвертого уровня число операций оказывается не маленьким. Каждый процесс, каждую операцию, в идеале, нужно оптимизировать, регламентировать и пересматривать хотя бы раз в год или по мере изменения внешних условий. Учитывая количество операций, понимаем, что идеал, как обычно, недостижим, а погоня за ним приведет лишь к неоправданному перерасходу ресурсов. Приходится принимать грустное, но верное решение – взяв стратегическую карту, проектировать лишь те бизнес-процессы, которые соответствую указанным в ней целям. И, если уборка внутренней территории не влияет ни на одну из целей или подцелей стратегической карты, не воздействует ни на один показатель из ССП – то пусть ее регламентируют сами уборщики. Хотя бы до тех пор, пока мы не разобрались окончательно с производством, сбытом и снабжением…
Степень детализации должна соответствовать нашим потребностям. Одна из причин, по которой нельзя допускать чрезмерной детализации, изложена выше – неоправданное увеличение объема работ. Другая напоминает старую притчу о сорокавосьминожке – если слишком подробно расписать для работника простые естественные действия, то выполнение их может стать неэффективным. Основной критерий в данном случае прост – если достигнуто четкое разделение обязанностей между сотрудниками и заданы основные принципы выполнения операций, то дальнейшая детализация не обязательна. Достаточно указать, что, например, при получении заявки, сотрудник должен распечатать соответствующий счет и задать время исполнения – не указывая, какие комбинации клавиш следует использовать для перемещения по ячейкам, сохранения и печати файла.
Не забывать при проектировании задавать основные параметры бизнес-процесса (рисунок 5).
Рисунок 5. Не забудьте указать параметры бизнес-процесса.
К ним относятся, например, время исполнения и стоимость. Проектирование в большинстве случаев является только одной из задач в процессе реинжиниринга системы управления. Рано или поздно появится желание произвести оптимизацию – вот тогда эти цифры и пригодятся. Впрочем, когда оптимизация не входит в ближайшие планы, с этим можно и повременить… если вас не тревожит, что на распечатку счета сотрудникам может потребоваться несколько часов или суток.
Оценка проблемности и важности процесса. Также позволяет понять, какие процессы следует проектировать сразу, а какие могут и подождать. Среди основных критериев здесь могут быть рассмотрены: 1) критичность для бизнеса. То есть насколько неправильное исполнение процесса может навредить компании – повысить затраты, привести к потере клиента, задержать принятие важного решения… 2) Частота повторения процесса (редко, часто, регулярно). 3) Количество передач ответственности в рамках одного процесса, например, от подразделения к подразделению. Такие процессы потенциально опасны и тянут за собой множество проблем.
Лидеры по всем трем номинациям – явные кандидаты к проектированию и оптимизации.
Очень важным является понимание принципов распределения зон ответственности на предприятии. Существует два основных варианта распределения – функциональный и процессный. При первом варианте предприятие делится на подразделения по функциональному принципу: например, ремонтные цеха, обрабатывающие, сборочные, службы поставок, отдел сбыта. И тогда один и тот же цех может выпускать кузова для, например, комбайнов и автомобилей. При процессной схеме предприятие делится на подразделения, обеспечивающие выпуск различной продукции или услуг. То есть, при втором способе одно подразделение выпускает и продает автомобили, второе – комбайны. И каждое из них содержит ремонтные, обрабатывающие и сборочные цеха или бригады, логистические службы и т.д. Преимущество первого подхода – экономия ресурсов. Но это преимущество часто оборачивается серьезным недостатком, размыванием ответственности за конечный результат среди слишком большого количества участников деятельности. Например, при этом подходе можно ограничиться одним технологом по окраске кузовных деталей (но этот спец, не имея четкой зависимости от продаж конкретной продукции, имеет все побудительные мотивы для того, чтобы работать спустя рукава, пользоваться неразберихой в разбросе работы между разной продукцией). Во втором случае – нужно уже два (причем с такой же примерно зарплатой для каждого). Преимущество второго подхода – концентрация усилий каждого подразделения в первую очередь на конечном результате. Моделирование бизнес-процессов в первом случае – для функционального построения предприятия – должно производиться с максимальной тщательностью в тех случаях, когда процессы переходят из ответственности одного подразделения к ответственности другого. Разумная рекомендация – делить процессы на несколько частей, за каждую из которых отвечает только одно подразделение. При процессной организации большинство бизнес-процессов остаются в рамках одного подразделения и, кроме того, имеют более логичную структуру. Вспомним приведенный выше процесс разработки нового изделия (рисунок 4), распределенный между пятью функциональными подразделениями. Каждое из производств имеет свой план (синие стрелки). Красные стрелки символично сделаны пунктирными – ведь этот процесс, как таковой, цехам не нужен, сложен и мешает «давать план». Отделы разработки и маркетинга не распоряжаются в цехах… Теперь становится понятно, что скрывается под кружочками с буквой «Д» - это управляющие воздействия директора, который оказывается единственным человеком, способным заставить цеха выполнять нестандартную работу. Эти функции вежливо называют склеивающими, по сути же они являются паразитными, излишними – той платой, которую приходится отдавать за экономию ресурсов при функциональном построении. А ниже – на рисунке (рисунок 6) – пример процессного подхода, создано отдельное производство для разработки новой продукции. Дорого? Да, конечно. Эффективно? Надо подумать…
Рисунок 6. Иллюстрация процессного подхода
Следует заметить, что эти два подхода редко встречаются в ярко выраженном виде. Так, отдел кадров большого предприятия почти всегда один обеспечивает нужды всех подразделений, в то же время производство заметно различающейся продукции очень часто организуется в раздельных частях предприятия. Таким образом, задача определения того, какой подход имеет место быть на данном предприятии (а также какой должен быть реализован на самом деле), должна решаться одной из самых первых в ходе работы над проектом. Ведь чем более предприятие тяготеет к функциональному построению, тем более запутаны бизнес-процессы, и тем ответственнее и сложнее задача их проектирования. Рекомендация переходить на процессное управление не всегда уместна – ведь, например, в таком случае придется делить все ресурсы по подразделениям, что невозможно по отношению к уникальным ресурсам (например, энергетическая подстанция), и может оказаться невыгодным экономически. Другой пример – Такелажный цех в составе десяти человек способен передвинуть станок, весящий 2-3 тонны. Если этот цех раскидать по пяти бригадам в различные подразделения, то передвинуть такой станок вдвоем окажется невозможно. Придется в каждом подразделении держать бригаду из десяти человек – и не факт, что они постоянно будут загружены работой.
Учесть неминуемое сопротивление сотрудников предприятия всему, что тем или иным образом будет разрушать сложившуюся систему отношений. Так, начальник такелажного цеха вряд ли обрадуется понижению в должности до бригадира, и будет искать все возможные способы саботировать принятие такого решения. Сотрудники будут преувеличивать важность своей работы – и добиваться снижения значимости работы других подразделений. Начальники подразделений будут оттягивать на себя выгодные бизнес-процессы и всячески открещиваться от ответственности за необходимый вклад в «чужие» процессы. Хотя, разумеется, есть очень сильная зависимость от стимулирования инноваций для конкретных исполнителей (которые, в большинстве своем, вовсе не заинтересованы в любых переменах, даже если они и сулят в будущем что-то очень хорошее, ведь повышение эффективности с их точки зрения означает возможность сделать для своего работодателя больше за те же деньги).
Что ожидаем в итоге
Конечным результатом проектирования должно стать предприятие, функционирующее по новой схеме. Одним из важнейших финальных продуктов проектирования является необходимый и достаточный набор регламентирующей документации.
Рисунок 7. Диалоговое окно, конечно, придуманное. Но разве это не намек на идеальное решение?
Регламенты бизнес-процессов (по крайней мере, ключевых), стандартные бланки документации, как наружной, так и внутренней, положения о подразделениях, должностные инструкции, штатное расписание предприятия – вот ее минимальный перечень. Не менее важно и внедрение системы, реализация регламентов на практике. Только после этого можно говорить о том, что силы и ресурсы на проектирование потрачены не напрасно. Хорошо, если удастся разделить внедрение на небольшие этапы и участки (например, сначала отдел закупок, потом складское хозяйство и т.п.) Помимо того, что это позволит сохранять уверенный контроль за процессом внедрения инноваций, каждый небольшой успех будет становиться хорошим стимулирующим фактором для продолжения дальнейшей работы. Правда, возможность разделить внедрение на отдельные независимые участки имеется далеко не всегда. Даже если новая система полностью позволяет избежать разделения ответственности между подразделениями, если структура новых бизнес-процессов строго линейна и проста – даже тогда необходимость внедрять измерения «на ходу» (кто же позволит остановить предприятие, приносящее прибыль?) приводит к тому, что внедрение одного нового процесса затрагивает десятки старых, которые, в свою очередь, заменены десятками «новых», каждый из которых… (и далее, по нарастающей). Поэтому в большинстве случаев по ходу внедрения коллектив вынужден какое-то время работать по старой системе, параллельно имитируя новую деятельность (большинство ваших сотрудников люди грамотные и прекрасно понимают, что долгое время придется делать двойную работу только ради того, чтобы итоговая нагрузка на них возросла бы по сравнению с изначальной – отсюда и сопротивление инновациям). В наиболее запущенных случаях для внедрения системы управления оказывается проще построить недалеко новый завод (именно так приходится поступать, например, на «АвтоВАЗе», где унаследованные из советских времен несуразности, помноженные на благоприобретенные в процессе перестройки создали среду, инновациям в которой сопротивляется практически каждый сотрудник). И, наконец, еще один закономерный результат проектирования – внедрение автоматизированной системы управления предприятием. Давно доказано, что автоматизация повышает эффективность работы. Особенно заметный эффект автоматизация дает на предприятиях, где имеется четкая и рациональная система управления, регламентированы все бизнес-процессы. И, напротив, автоматизировать управление без предварительного проектирования – значит обречь внедрение АСУ на провал (мы уже упоминали невозможность автоматизации неопределенным образом происходящих случайно возникающих взаимоотношений?). Наличие же строгой системы бизнес-процессов позволит подойти к внедрению АСУ с точки зрения максимальной эффективности. Теперь уже вполне реально автоматизировать сначала наиболее критичные участки работы, на вырученные или сэкономленные в результате деньги – следующие по важности… Можно делать это с той постепенностью, какую позволяют ресурсы или требует внешняя ситуация.
Оценка потребности в ресурсах
Если вам ранее доводилось заниматься подобной деятельностью – то вы уже представляете себе, насколько облегчит проектирование Ваш расчетный счет, скольких сотрудников вы временно потеряете, как полноценные боевые единицы (и скольких вообще потеряете). Рассуждения ниже скорее для тех, кто впервые планирует приступать к такой работе – ведь опасно как переоценить, так и недооценить масштабы грядущих потерь. Завышенная оценка сложности может привести к отказу от проекта вообще (вместе с надеждами стать лидером отрасли), либо к излишне высоким суммам по договору с исполнителем. Заниженная оценка приведет к тому, что в какой-то момент ресурсов не хватит и проект будет заброшен – что снова означает потерянные деньги. Временная оценка не менее важна – и по тем же соображениям. Практика показывает, что компании среднего размера – от 500 до 1000 человек – разрабатывают и внедряют новую систему управления целиком за один год. Компаниям с 10 тыс. сотрудников потребуется примерно 2-3 года. Впрочем, в зависимости от сложности ситуации, время внедрения может увеличиться и в два и в три раза.
Из потребности в людских ресурсах можно предположить на весь этот период постоянную команду из 3-4 человек (стратег, аналитики) и необходимость привлечения к работе сотрудников предприятия по мере необходимости – начальников подразделений и рядовых исполнителей. Начальники будут привлекаться, приблизительно на один-два месяца чистого времени на протяжении всего цикла проектирования и внедрения, рядовые исполнители – меньше, от 2 недель до месяца. Затраты на своих специалистов, учитывая это время, можно оценить. Внешние консультанты стоят недешево. Услуги специалиста могут обойтись от 1,5 до 25 тыс. рублей за час работы.
Немного о гарантиях успеха. Мы уже говорили, что занимаясь проектированием системы управления самостоятельно, опытный и здравомыслящий руководитель при поддержке команды своих заместителей имеет неплохие шансы произвести эту работу без привлечения внешних консультантов – хотя, конечно, идеального результата с первого раза такой коллектив не добьется. Возможности профессиональной команды больше – и чем более известную (и дорогую) консалтинговую компанию Вы пригласите – тем ближе окажетесь к идеалу управленческой системы для вашего вида деятельности. Известная компания, как правило, дорожит своей репутацией, ее специалисты в процессе предпроектного обследования могут сделать вывод об эффективности предстоящей работы – а могут и отказаться, если, по каким-то причинам, успех проектирования не гарантирован. В последнее время появился еще один подход – на время внедрения ведущий консультант принимается на работу в компанию-клиент в качестве топ-менеджера – директором или заместителем. Конечно, репутация консалтинговой компании должна быть для этого очень высокой – но зато можно быть уверенным в получении результата высокого качества, при заметной экономии нервных клеток. Малоизвестная компания может обойтись дешевле – но и результат далеко не гарантирован.
Вопрос: Можно ли снизить затраты на проектирование системы управления?
Ответ: Можно и нужно. Способом снизить потребность в ресурсах является использование специализированных программных продуктов.
Первая причина, по которой автоматизация проектирования действительно полезна – это возможность сохранения и редактирования на каждом этапе работы. Созданные и сохраненные бизнес-процессы «как есть» заметно облегчают моделирование процессов «как будет» - ведь редактировать проще, чем создавать заново.
Вторая причина берет исток в понимании основ эффективности. Часто повторяющиеся процессы являются критичными для общего хода дела – ведь, несмотря на простоту и шаблонность, их вклад в общие трудозатраты весьма значителен. В проектировании бизнес-процессов достаточно много шаблонных, повторяющихся действий, которые, при ручной работе, заберут львиную долю всего времени разработки. Конечно, применение методик CTRL-C – CTRL-V заметно облегчает работу в WORD или Excel при их вводе, однако специализированное ПО предоставляет еще более удобную среду для проектирования.
Третья причина – взаимосвязанность всех объектов– от подразделений и сотрудников до процессов различного уровня и стратегических целей. В грамотно построенной системе все должно подчиняться единой стратегической системе целей. Специализированное ПО обеспечивает такую взаимосвязь, помогает избежать досадных просчетов от невнимательности при вводе информации.
Четвертая причина – возможность оптимизации. Пусть на сегодняшний день и не существует программы, способной самостоятельно спроектировать оптимальный вариант бизнес-процесса (иначе и необходимость в руководителях и бизнес-аналитиках отпала бы сама собой, компьютер дешевле) – но произвести симуляцию сотен циклов прохождения каждого из тысяч бизнес-процессов в десятках вариаций их взаимодействия… Попробуйте проделать это с помощью Excel! А без статистической обработки в данном случае не обойтись – ведь система будет работать в реальном мире, где всякое случается.
Пятая (и, для многих, самая важная) причина – автоматизация вывода результата. Даже самая великолепная система управления останется лишь проектом до тех пор, пока бизнес-процессы не превратятся в регламенты и должностные инструкции. Система, способная автоматически выработать все эти сотни и тысячи регламентирующих документов, да еще и довести их до каждого сотрудника сбережет руководителю очень большое количество его очень недешевого времени. Конечно, при коррекции бизнес-процессов (а их просто-таки настоятельно рекомендуется проверять на жизненность хотя бы ежегодно) автоматизированная система не забудет внести изменения во все документы, затронутые изменениями – и вновь довести до сотрудников новые правила игры. Нельзя забывать и о том, что автоматически формируемые регламенты согласованы между собой и непротиворечивы (если, конечно, бизнес-процессы спроектированы верно) и сотрудникам уже не удастся использовать «дыры» в вашем внутреннем законодательстве.
Рисунок 8. Большое количество регламентов не так просто состыковать… Если не пользоваться автоматизированной системой моделирования.
Шестая причина. Важная, скорее, для начинающих проектировщиков. Инструкция к специализированному программному обеспечению уже сама по себе является изложением основ моделирования бизнес-процессов. Работая по намеченному в ПО шаблону, новичок не допустит каких-либо досадных ошибок, система не позволит пропустить какие-либо важные действия или шаги, благодаря чему шансы на успех проектирования возрастают в значительной степени.
Первый способ – есть не что иное, как последовательное текстовое описание бизнес-процесса. Примером текстового описания фрагмента бизнес-процесса является следующий текст: "Отдел продаж составляет договор и согласует его с Юридическим отделом".
Многие российские компании разработали и используют в своей деятельности регламентирующие документы, часть из которых является процессными регламентами и представляет не что иное как текстовое описание бизнес-процессов.
Для целей анализа и оптимизации деятельности компании данный не подходит. Дело в том, что описание бизнес-процесса в текстовом виде системно рассмотреть и проанализировать невозможно. Текстовая информация воспринимается человеческим мозгом последовательно. Например, когда человек читает регламент, и доходит до его конца, практически всегда он забывает про то, что было в начале документа. Второй недостаток текстового представления бизнес-процесса связан с тем, что человеческое сознание устроено так, что оно эффективно может работать только с образами. При восприятии и анализе текстовой информации человеческий мозг раскладывает ее на ряд образов, на что уходит дополнительно временя и умственные усилия. Поэтому при использовании текстового описания бизнес-процессов производительность и качество решений по оптимизации деятельности оставляют желать лучшего, что особенно сильно проявляется, когда решение принимается группой людей.
В свое время специалисты по информационным технологиям разработали более структурированный подход к описанию бизнес-процессов. Ими было предложено разбить бизнес-процесс по ячейкам структурированной таблицы, в которой каждый столбец и строчка имеют определенное значение. Данную таблицу читать более просто, из нее легче понять, кто за что отвечает, в какой последовательности в бизнес-процессе выполняются работы, и соответственно бизнес-процесс проще проанализировать. Табличная форма описания бизнес-процессов более эффективна по сравнению с текстовой и в настоящее время активно применяется специалистами по информационным технологиям для описания бизнес-процессов в приложении к задачам автоматизации.
[1] Ковалев С. М., Ковалев В. М. Технология структуризации и описание организации – шаг за шагом //Консультант директора №8 (212), Апрель, 2009 г.
[2] Плотникова Н.И. Комплексная автоматизация туристского бизнеса. 4.1. Информационные технологии в сфере гостеприимства: учебно-методическое пособие. М.: Советский спорт, 2010.
В настоящее время распространено использование двух инструментов описания бизнес-процессов, которые принято называть вертикальным и горизонтальным описанием бизнес-процессов.
При вертикальном описании показывают только работы и их иерархический порядок в дереве бизнес-процесса. В этом случае имеются только вертикальные связи между родительскими и дочерними работами.
При горизонтальном описании бизнес-процесса также показываются, как эти работы между собой взаимосвязаны, в какой последовательности они выполняются, какие информационные и материальные потоки между ними движутся. В этом случае в модели бизнес-процесса появляются горизонтальные связи между различными работами, которые процесс составляют (рисунок 1.1).
Бизнес-моделирование (моделирование бизнес процессов) — деятельность по выявлению, описанию и имитации существующих бизнес-процессов (анализ бизнес-процессов), а также проектированию новых (проектирование бизнес-процессов) с целью их последующего анализа и оптимизации.
Бизнес-моделированием также называют дисциплину и отдельный подпроцесс в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе — те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе.
Моделирование бизнес процессов играет огромную роль в управлении бизнес процессами. Необходимо отметить, что в английском переводе оба вида деятельности имеют одинаковую аббревиатуру BPM (Business Process Modeling и Business Process Management, соответственно), что часто приводит к путанице. Данный факт необходимо учитывать т.к. большинство литературы по данному предмету на английском языке. Графическое описание бизнес-процессов и их имитация это методы анализа бизнес-процессов, эффективность которых доказана многолетней практикой использования и многочисленными исследованиями. Для графического представления бизнес процессов используются различные языки, но наиболее популярными и подходящими считаются UML и Business Process Modeling Notation.
Моделирование и имитация бизнес процессов являются ключевыми методами для реинжиниринга бизнес-процессов (Business Process Reengineering) и использования методологий непрерывного улучшения бизнес-процессов, например, такими как Six-Sigma.
По каким критериям необходимо выбирать BPMS?
Аналитики компании Gartner предлагают обратить внимание на следующие требования при выборе BPM-системы:
поддержка задач «человек-человек» и удобство интерфейса пользователя;
поддержка организационной структуры и ролевых групп;
возможность переназначения заданий, оперативного вмешательства в процесс и обработки исключительных ситуаций;
возможность управления логикой процесса с рабочего места пользователя;
удобство использования и администрирования;
присутствие графических средств разработки моделей бизнес-процесса;
поддерживаемые архитектуры и стандарты;
производительность и масштабируемость;
способность обслуживать многочисленные, продолжительные и распределённые процессы;
понятный интерфейс настройки и возможность минимального участия ИТ-специалистов во внедрении и поддержке;
возможность информирования в реальном времени по отклонениям показателей процесса;
поддержка сервис- ориентированной архитектуры (SOA — Service Oriented Architecture);
присутствие шаблонов бизнес-процессов, на основании которых могут быть разработаны новые процессы;
невысокая совокупная стоимость владения.
В традиционных организационных структурах обычно устанавливаются границы взаимодействия между подразделениями, и определяется иерархический порядок принятия решений. В функциональном подразделении работают сотрудники, выполняющие одинаковую работу, и в каждом подразделении выполняется небольшой элемент бизнес-процесса. В результате бизнес-процесс становится фрагментарным, то есть разбитым на отдельные отрезки, каждый из которого выполняется в отдельном подразделении. При такой системе управления бизнес-процесс не является работой одного человека или одного функционального подразделения, а участвующие в процессе работник или подразделение несут ответственность за выполнение одной простой операции. Работа менеджеров при этом в значительной степени состоит в контроле за исполнителями и в объединении отдельных работ в единый процесс.
В такой ситуации:
Никто не отвечает за процесс в целом и его результаты;
Такой процесс подвержен сбоям, так как многие работники вынуждены действовать независимо друг от друга;
Процесс, в котором задействованы работники различных подразделений, трудно сделать гибким.
Кроме того, работники не являются организационно и функционально интегрированными и разбросаны по различным подразделениям. Возникает проблема несогласованности и даже противоречивости целей различных исполнителей.
Эффективность на разных этапах бизнес-процесса может оцениваться по совершенно разным показателям, противоречащим друг другу. В результате эффективность отдельных подразделений предприятия может достигаться в ущерб общей эффективности. Например, работники, участвующие в осуществлении одного бизнес-процесса могут иметь несовместимые цели. Один исполнитель может заботиться об оборачиваемости товарно-материальных запасов, а другой о времени доставки товаров и т.д.
4. Инжиниринг процесса как метод совершенствования процессов организации воспринимается сегодня неоднозначно. Само понятие «инжиниринг» заимствовано из инженерной деятельности (от англ. engineering — проектировать, изобретать, придумывать). Некоторые исследователи рассматривают инжиниринг процессов как общее понятие, включающее реинжиниринг бизнес-процессов и совершенствование бизнеса. Другой позиции придерживаются А. Большаков и В. Михайлов, которые считают инжиниринг новым способом мышления, формирующим взгляд на построение компании как на инженерную деятельность. Более детальное исследование инжиниринга было предпринято П. Кутелевым. Он, в частности, выделяет понятие «организационный инжиниринг» и характеризует его как проектирование бизнес-процессов, объединенных в едином информационном поле. Ряд исследователей выделяют понятие бизнес-инжиниринг и определяют его как проектирование бизнес-процессов и систем управления компанией «с чистого листа».
Инжиниринг как метод совершенствования процессов функционирующей организации, по нашему мнению, сложно представить исходя лишь из того, что если функционирует организация, то уже осуществляется деятельность, значит, хотим мы того или нет, существуют и процессы деятельности. Насколько они интегрированы и оптимальны — это вопрос другого порядка. Его можно решить посредством различных подходов к проектированию. Поэтому было бы справедливо инжиниринг процесса (процессов) считать методом проектирования бизнес-процессов вновь создаваемых организаций или бизнес-процессов новых видов бизнеса в существующих организациях с учетом передового опыта и принципа оптимальности в управлении процессами. В зависимости от того, на какую модель управления будет ориентирован инжиниринг процесса — функционально-
Описание бизнес-процесса. Способы описания бизнес-процессов:
Текстовое описание
Графическое представление процесса, например в виде диаграмм
Смешанный вариант (диаграммы + текстовые пояснения)
Для создания такого описания необходимо ответить на вопросы:
Кто потребитель БП и что служит выходом бизнес-процесса
Кто поставщик БП и что служит входом бизнес-процесса
Какие требования предъявляются к выходам и входам этого БП
Каковы операции, входящие в состав этого БП.
На верхнем уровне описывается логика функционального взаимодействия участников бизнес-процесса, на нижнем уровне – технология работы отдельных специалистов на своих рабочих местах.
Процессная модель предприятия должна строиться с учетом следующих положений:
Верхний уровень модели должен отражать только контекст бизнес-процесса
Уровнем ниже должны отображаться тематически сгруппированные бизнес-процессы (деятельность) предприятия и их взаимосвязи.
На следующем уровне деятельность должна быть детализирована на процессы.
Далее, процессы детализируются посредством функций.
И на последнем уровне описание функций осуществляется с помощью миниспецификаций.
Процессные потоковые модели отвечают на вопросы: ЧТО? – КОГДА? – КТО? – КАК? – КОМУ?
Методы проведения обследования предприятия. Основные методы:
1. Анкетирование – в основном применяется к руководителям подразделений. С помощью анкет собирается следующая информация:
2. ФИО руководителя подразделения, телефон;
3. координаты контактного лица (к кому в отсутствие или при занятости руководителя можно обращаться);
4. каковы (с позиций Вашего подразделения) должны быть цели создания интегрированной системы управления предприятием;
5. основные функции подразделения;
6. какая информация поступает из других подразделений (заявки, запросы, отчеты и т.п.);
7. какая информация передается в другие подразделения;
8. какая информация формируется в подразделении;
9. с какими внешними предприятиями (банк, заказчик, поставщик и т.п.) взаимодействует подразделение и какой информацией обменивается;
10. физическое представление информационных потоков и хранилищ (документ, сеть, журнал, картотека и т.п.);
11. период хранения информации;
12. документы от и для руководства;
13. штатная структура и квалификация кадров;
14. техническое оснащение подразделения (компьютеры, сеть, модем и т.п.);
15. используемые программные продукты;
16. подпись.
17. Сбор и анализ документов – результатом этого этапа должен стать альбом форм с разбивкой по видам деятельности (в каждом виде деятельности может быть определена дополнительно внутренняя классификация документов по отдельным признакам).
18. Интервьюирование – должно дать ответы на следующие вопросы:
19. Внешние объекты, с которыми взаимодействует предприятие, технологии взаимодействия со стороны предприятия, а также информационные (и, возможно, материальные) потоки, обеспечивающие эти взаимодействия;
20. Детальная информация о реальных технологиях работы предприятия и его подразделений (нормативно-справочная информация не всегда полно описывает эти технологии);
21. Должны быть определены реальные функции подразделений и их взаимосвязи и взаимозависимости, т.к. положения о работе подразделениий такой информации зачастую не содержит;
22. Должны быть специфированы все информационные хранилища, в том числе и бумажные;
23. Детальная информация об аппаратно-технической и телекоммуникационной базе предприятия;
24. Статистические данные по бизнес-процессам предприятия.
Инжиниринг Бизнес-процессов начинается со стратегического корпоративного планирования. На этом этапе определяются группы продуктов (услуг) и базовые корпоративные процессы. Продукты (услуги), разумеется, создаются в результате реализации процессов, а необходимые Бизнес-процессы разрабатываются с учетом особенностей данного вида деятельности.
Комплексное моделирование продуктов и процессов применительно к каждому продукту (услуге) позволяет унифицированно управлять Бизнес-процессами. Обязательной предпосылкой для определения стоимости продуктов (услуг), согласованного планирования и управления Бизнес-процессами является наличие процедуры оценки стоимости самих Бизнес-процессов. Для этого можно использовать методику ABC-анализа, которая позволяет определить стоимость выполнения каждой функции, Бизнес-процесса, более точно перераспределить накладные расходы на вырабатываемые продукты (услуги) путем отнесения затрат на функции, а затем на продукты (услуги). Эта проблема особенно актуальна для сервисных компаний (туристические компании, банки, телекоммуникации и др.), где успех бизнеса в большой степени зависит от оптимальности Бизнес-процессов (непроизводственных процессов), а следовательно, важно точно знать, сколько стоит предоставление тех или иных услуг с учетом всех накладных расходов.
Ключевую роль в формировании продуктов (услуг) играют не только сами процессы, но и их формы, которые определяют типы создаваемых продуктов (услуг).
Необходимость
совершенствования
бизнес-процессов
привела
к
созданию
методологии управления процессами (МУП), которая включает шесть основных шагов:
Шаг 1.
Определение владельца(ев) процесса
Шаг 2.
Описание границ и интерфейсов процесса
Шаг 3.
Описание самого процесса с помощью программного инструментария
Шаг 4.
Установка точек контроля за процессом
Шаг 5.
Измерение показателей процесса в точках контроля
Шаг 6.
Анализ полученной информации и предложения по совершенствованию
КАК РАЗРАБАТЫВАЕТСЯ СИСТЕМА БИЗНЕС – ПРОЦЕССОВ.
Бизнес-процесс представляет собой систему последовательных, целенаправленных и регламентированных видов деятельности, в которой посредством управляющего воздействия и с помощью ресурсов входы процесса преобразуются в выходы, результаты процесса, представляющие ценность для потребителей (А.Г. Шугаев). Ключевыми свойствами бизнес-процесса является то, что это конечная и взаимосвязанная совокупность действий, определяемая отношениями, мотивами, ограничениями и ресурсами внутри конечного множества субъектов и объектов, объединяющихся в систему ради общих интересов с целью получения конкретного результата, отчуждаемого или потребляемого самой системой.
Система бизнес – процессов устанавливает, какой комплекс ключевых действий нужно совершить, чтобы добиться достижения стратегических целей.
Система бизнес – процессов служит фундаментом для определения потребностей в компетенциях, квалификации кадров, численности, в материальных и нематериальных ресурсах, инфраструктуре для реализации стратегии.
На основании стратегии и тактики производим проектирование (инжиниринг) бизнес – процессов, то есть, устанавливаем - какие основные процессы необходимы по потребителю, товару, рынку в разрезе функций управления: маркетинг, производство, сбыт, управление, какие обеспечивающие процессы необходимы для осуществления общей деятельности.
Инжиниринг (англ. engineering, лат. ingenium) — изобретательность; выдумка; знания. Инжиниринг — это набор приемов и методов, которые компания использует для проектирования бизнеса в соответствии со своими целями.
Инжиниринг бизнес – процессов подразумевает:
1. Анализ деятельности (разделение) по составляющим процессам и операциям.
2. Технологию процессов – последовательность операций в процессах.
3. Необходимые ресурсы для выполнения процессов. Проектирование системы ресурсов.
4. Синтез процессов (взаимодействие) в общие результаты: балансировка, узкие места, синергия.
5. Содержание труда в процессах: сложность, трудоемкость.
6. Производительность процесса. Факторы, влияющие на производительность.
7. Показатели результативности процессов.
Инжиниринг отражается в форме модели (моделирование системы процессов) при запуске деятельности, изменениях в деятельности, внедрении новых видов деятельности.
Реинжиниринг осуществляется по периодам времени, в случаях снижения показателей, изменения стратегии, внедрения инноваций и других случаях.
Критерии выделения бизнес – процессов:
1. Направленность на цели.
2. Продукт (внешний или внутренний) - результат выполнения процесса.
3. Прямое или косвенное участие в доходах.
4. Технологическая необходимость, от процесса нельзя отказаться.
Свойства бизнес – процессов:
• Причинно – следственные связи.
• Альтернативность в выполнении, способах, средствах выполнения.
• Производительность (количество).
• Качество.
• Сложность.
• Трудоемкость.
• Повторяемость.
• Конкурентные преимущества.
Технология инжиниринга бизнес – процессов:
1 этап – разработка матрицы задач.
На основании целей, стратегии и тактики (СУРС) производится анализ стратегических действий для разработки составляющих задач по достижению целей на основании причинно – следственных связей. Что нужно сделать, чтобы достичь целей, реализовать стратегию и тактику, какие задачи решить. Результаты сводятся в матрицу.
Внешняя среда к области деятельности:
► Отрасль деятельности: уровень развития, достижения, направления развития.
► Мировой рынок: состояние, перспективы развития, конкуренция.
► Государство: макроэкономика, тенденции развития, условия (законодательство, финансовая политика, налоговая политика и т.д.).
► Потребительский рынок: характеристики, параметры, конкуренция, перспективы, альтернативы в спросе и предложении, ценовые факторы, способы продаж, преимущества.
► Рынки ресурсов: состояние, тенденции, альтернативы, стоимостные факторы, контролируемость источников и т.д.
Внутренняя среда:
► Производственные факторы: место, где будет осуществляться деятельность, инфраструктура, материальные факторы, нематериальные факторы и другие движущие силы развития.
► Управленческие факторы: предпринимательские способности, лидерские качества, стиль, способы управления, компетенции и другие.
2 этап – разработка действий по выполнению задач.
Из поставленных задач вытекают действия – процессы, которые необходимы для их решения.
Процессы проектируются с учетом критериев и свойств, направлены на решение задач в разрезе управленческих стратегий: маркетинг, разработка и производство, сбыт, управление деятельностью. Проектирование осуществляется на основе технологий с выделением составляющих операций (последовательно и параллельно выполняемых), обеспечивающих продуктивность деятельности. Технологии могут использоваться, как собственной разработки, так и заимствованные. Оценка применяемых технологий производится по критериям:
1. Уровень к мировым достижениям.
2. Прогрессивность – способность к развитию, модернизации, реинжинирингу.
3. Соответствие стратегии и тактике.
4. Оптимальность к возможностям: стоимость, компетенции, риски, финансирование и другие.
5. Непротиворечивость другим бизнес процессам, соответствие принципу МЕСЕ - аббревиатура от Mutually Exclusive, Collectively Exhaustive— «взаимно исключающие, совместно исчерпывающие».
После выбора технологий бизнес – процессов осуществляется их синтез в общую систему для обеспечения синергии усилий. Искусство синтеза состоит в создании системы, обеспечивающей необходимую производительность (определяется наиболее узкими местами), качество, взаимодействие и взаимодополнение отдельных бизнес – процессов для выполнения задач. Искусство проектирования бизнес – процессов требует высокой компетенции и квалификации специалистов его осуществляющих, периодического анализа и аудита, так как во многом определяет результативность и эффективность деятельности.
«Успех – это несколько правильных действий, повторяемых ежедневно, а неуспех – набор неправильных действий, повторяемых ежедневно (Джим Рон).
3 этап – определение результативности бизнес – процессов.
«Вы не можете управлять тем, что не можете оценить» (В. Хьюлетт, основатель компании Hewlett Packard).
Спроектировать бизнес – процессы недостаточно, нужно ими управлять в дальнейшем для оценки их результативности и эффективности, иначе они могут тормозить развитие, сводить на нет даже гениальные решения, поэтому необходимо постоянно измерять и оценивать их результативность и эффективность. Измерение и оценка производятся посредством показателей.
Таблица общих показателей результативности и эффективности бизнес – процессов.
Измерение и контроль показателей осуществляются по периодам и в порядке, устанавливаемыми стандартами компании.
Для измерения конкретных бизнес – процессов используются дополнительные показатели, отражающие их особенности.
4этап – установление способов осуществления процессов, порядка совершенствования, внедрения инноваций.
Для каждого бизнес – процесса следует на основании экспертных оценок, анализа внешней среды разработать способы осуществления. Разработка способов подразумевает:
1. Выбор приемов и методов труда.
2. Выбор степени автоматизации.
3. Установление уровня стандартизации, сертификации.
4. Определение потребности в материалах, средствах производства, использования нематериальных активов, условий труда и других факторах.
5. Проведение мониторинга по инновациям в процессе.
6. Установление порядка изучения инноваций и их внедрения.
Анализ бизнес – процессов:
1. Значимость процесса: ключевой, обычный. Роль процесса в результате (доходе).
2. Сколько процесс может произвести результата (производительность).
3. Сколько процесс стоит (себестоимость + финансовые издержки по пассивам).
4. Кто оплачивает – потребитель, изготовитель.
5. Зачем процесс нужен, можно ли обойтись без него. Да, нет - последствия.
6. Есть ли альтернативы в реализации процесса: сами, аутсорсинг, другие.
7. Можно ли сократить издержки (автоматизация, технологии, приемы труда и другие).
8. С какими процессами взаимодействует: от каких зависит, какие зависят от него, как взаимодействуют, как синергия.
9. Результат процесса – в чем продукт (внешний и внутренний).
10. Эффективность процесса – результат минус затраты, выгоды, польза.
11. Перспективы процесса: разработка ноу – хау, инноваций и т.д.
12. Оснащенность процесса.
13. Сложность – квалификация.
14. Качество: уровень, брак, конкуренция.
15. Какие ресурсы обеспечивают бизнес – процесс.
5 этап – утверждение системы бизнес – процессов.
Система утверждается в установленном порядке и обязательна к применению и исполнению.
После утверждения системы процессов, она служит основанием для структурирования деятельности по составляющим направлениям деятельности, расчета ресурсов, подбора кадров, внедрения системы качества.
Осуществление бизнес – процессов претворяется в практику посредством систем управления: планирование, информация, измерение, контроль, анализ, мотивация. Каждый процесс должен поддерживаться функциональным обслуживанием: техническим, юридическим, экономическим, финансовым и другими.
В организации бизнес – процессов часто увлекаются формальной стороной, а не содержательной. Инжиниринг бизнес – процессов состоит в творческом анализе необходимых действий для технологичности, оптимизации затрат ресурсов, трудоемкости, производительности, качества. Красивые картинки в программных средствах служат для изложения сути, а не украшения деятельности для себя или инвесторов и не могут заменить настоящий инжиниринг.
Бизнес – процессы часто бывают излишними, вызывающимися из-за амбиций бюрократии, которые удовлетворяют личным интересам, а не интересам дела, а значит, ведут к повышенным издержкам при низком результате. Если процессы соответствуют стратегии и тактике управления, основываются на организационных задачах и показателях результативности и эффективности, то вероятность лишних действий значительно менее вероятна.
Особенность бизнеса в необходимости не только проектировать, выстраивать бизнес – процессы, но делать их гибкими. Проектирование позволяет применять автоматизацию, но при этом нужно понимать, что автоматизация, внедрение информационных технологий – это средства для повышения продуктивности бизнес – процессов, а не самоцель.
«Автоматизация беспорядка приводит к автоматизированному беспорядку» (Чампи, Хаммер).
Стремясь повысить эффективность своей фирмы, руководство часто не понимает, что улучшение отдельных звеньев процесса не решит общей проблемы – наоборот, это лучший способ гарантировать плохую эффективность и в дальнейшем. Множество компаний пытается наладить отдельные этапы работы вместо перестройки всего ее процесса.
Теперь компании должны быть организованы на основе ключевых процессов. Именно поэтому организация должна начинаться с бизнес – процессов.
Нужен периодический реинжиниринг бизнес – процессов. Когда?
По результатам периодического организационного аудита, при снижении показателей деятельности, при изменении стратегии, при внедрении инноваций.
Итак, система бизнес – процессов обеспечивает алгоритм деятельности:
Что делаем (действия: процессы, операции), на основании чего _ Чем обеспечиваются действия (инфраструктура, снабжение и др.) _ Как соединяются (управление) _ Что получаем в результате (продукт, показатели)
Смысл инжиниринга – содержание алгоритмов действий, а не форма их представления.
Система бизнес – процессов является базой для структурирования решений и действий, формирования ресурсной базы, подбора и расстановки кадров, системы обеспечения ресурсами.
Гибридная адаптивная технология проек
Аннотация. Объектом исследования является развитие автоматизированной системы трансформации компонент диаграмм языка структурного моделирования в диаграммы классов на основе гибридной адаптивной технологии проектирования бизнес-процессов, включающей IDEF0, UML, OWL, RDF, XML, XSLT. Показана возможность определения правил трансформации с использованием онтологического описания.
