Современный бизнес в некоторой степени отличается от бизнеса предыдущих поколений, если говорить о мире в целом, и в корне, кардинально – от предпринимательской деятельности в нашей стране, где было достаточно просто выполнять свою работу и производить определенный «плановый» продукт, без оглядки на внутреннюю эффективность. Но изменение политической ситуации в стране, мировой технический прогресс вместе с конкуренцией изменили вектор построения компаний, по сути, вынудив предпринимателей новой эры концентрировать свои усилия, в первую очередь, на продуктивности работы. Произошло сразу несколько серьезных преобразований бизнеса, бизнес-инструментов и бизнес-систем, одним из которых стало появление таких понятий, как процессное управление и бизнес-процессы.
О том, почему процессное управление сегодня – самый продуктивный метод управления бизнес-цепочками внутри компании, какую роль бизнес-процессы и их автоматизация играют в компаниях, каким образом, собственно, возможно автоматизировать процессы и что дает с точки зрения результативности система автоматизации бизнес-процессов компании – поговорим в сегодняшнем материале.
Развитие бизнес-процессов в современном мире
В некотором смысле бизнес-процессы существовали еще на заре предпринимательской деятельности. Интуитивно люди, которые занимались торговлей, уже выстраивали некоторые упорядоченные наборы последовательных действий, чтобы достигнуть какого-то результата в плане экономической эффективности. Тогда для них, скорее всего, это выглядело просто логичным или удобным способом организации своей предпринимательской деятельности. Поэтому термин «бизнес-процесс» вошел в употребление, означая нечто понятное на интуитивном уровне любому, кто занимается бизнесом.
Изначально бизнес процессы фактически представляли собой инструкции, фиксировавшие наиболее корректное описание того, как надо выполнять определенные действия. Технически это были разрозненные регламенты того, как компания выполняет те или иные процедуры. Позже предприниматели осознали необходимость работы с этими документами на более глубоком уровне. Это был первый опыт исследования бизнес-процессов, чтобы повысить их продуктивность.
В 20-х годах XX века процессы начали описывать не только словами и последовательностью, но простейшими блок-схемами с графическим оформлением взаимосвязей на подобии: «если сделать так – будет это, если сделать иначе, будет то». Потом пришло время связанных алгоритмов, вместе с которыми бизнес-процессы, как элемент управления эффективностью и предприятием в целом, все более формализуется и закрепляется в качестве MUST HAVE во всех отраслях предпринимательской деятельности.
С приходом компьютерной эры и открытием новых возможностей в части технического сопровождения бизнес-процессов, начались попытки перевода бизнес процессов в электронный вид, формирования устойчивых горизонтальных и вертикальных связей между различными процессами, а вместе с этим и первые попытки автоматизации небольших участков деятельности.
Все это и являлось прародителем будущей тотальной автоматизации бизнес-процессов, направленной на повышение эффективности компании. Впоследствии целый ряд разработчиков, увидевших потенциал автоматизации бизнеса и возможность разработки решения, которое можно будет внедрять фактически неограниченное количество раз в разных компаниях, вышли на рынок автоматизации и стали предлагать бизнесу различные решения в области бизнес процессов, применимые для любых функциональных уровней бизнеса.
Началось тотальное моделирование бизнес-процессов, появились электронные системы контроля и учета, качества, развились процедуры стандартизации и регламентирования нормативных показателей и путей минимизации отклонений от них.
Так сформировалась и продолжила свое развитие идея о необходимости строить ориентированный на результат бизнес, опирающийся на определенные стандарты. Фактически, это был ответ на вызов времени и необходимости повышать свою конкурентоспособность, это «ответ на вызов потребителей» и логичное развитие компаний и рынка.
Бизнес-процесс как ключ к успеху
Любая коммерческая компания ориентируется на единственный результат – заработок денег. Для достижения этой цели в компании, в зависимости от сферы ее деятельности и размера, осуществляется определенное количество действий. Все они при этом должны иметь определенный конечный результат, а совокупность этих результатов в итоге приводит компанию к реализации поставленной задачи и получению прибыли. Поэтому любая компания независимо от вида ее бизнеса, отрасли, географии и других характеристик будет представлять собой систему взаимосвязанных бизнес-процессов независимо от того, чем эта компания занимается.
Любой бизнес-процесс в компании, в свою очередь, имеет владельцев и цепочку участников, совместная работа которых в рамках определенного запланированного стандарта обеспечивает достижение нормативного результата. Помимо этого каждый процесс имеет заданные точки контроля, по которым владельцы процессов могут контролировать промежуточные результаты и при необходимости принимать управленческие корректирующие меры.
Именно в совокупности результатов различных процессов компании и заключается цель основной деятельности.
Сегодня управление бизнес-процессами стало не просто важной, а скорее неотъемлемой частью бизнеса эффективных предприятий. Сложно представить себе по-настоящему прогрессивную и экономически эффективную компанию, система организации которой не базировалась бы на процессном подходе к бизнесу. Составными частями бизнес-процессов регламентируются нормативные производственные показатели, расходы финансовых и производственных ресурсов, продуктивность персонала и фактически экономический потенциал предприятия.
Параллельно бизнес-процессы стали выполнять и еще одну важнейшую функцию: нейтрализацию влияния человеческого фактора. Независимо от степени технической оснащенности компании или уровня технического прогресса в компаниях все равно работают люди, а не роботы, поэтому на определенном организационном уровне влияние человеческого фактора проявляется в любом случае. Для того чтобы возникла возможность нормативного контроля действий персонала, в бизнес-процессах прописываются ключевые показатели эффективности для сотрудников компании, степень их ответственности и фактической продуктивности в рамках рассматриваемого процесса. Таким образом, обеспечивается органическое функционирование системы, в которой «все на своих местах» и контроль ведется не только за итоговой результативностью процесса, но и за вкладом в процесс каждого включенного в него звена бизнес цепочки.
С аналитической точки зрения система бизнес-процессов становится источником индикаторов, метрик и знаний для менеджмента организации, поскольку позволяет не только контролировать текущий статус, но и формировать прогнозы и сценарии для повышения эффективности компании в перспективе. Аналитика бизнес процессов, или как это принято называть в экономической литературе – исследование бизнес процессов, позволяет максимально детально рассматривать бизнес с точки зрения ориентира на продуктивность. Менеджмент при правильном подходе к модернизации процессов может постепенно улучшать практически все ключевые показатели компании:
- Улучшить производственный процесс с точки зрения его скорости, стоимости и качества продукции;
- Повысить продуктивность и эффективность персонала, а также вытекающие из этого вопросы личной финансовой мотивации и общего фонда расходов труда на персонал;
- Оптимизировать административный блок процессов и расходов операционного характера;
- Повысить качество внутренней структуры, порядка документооборота и внутренней операционной дисциплины в компании;
- Улучшить качество внешних и внутренних коммуникаций компании.
Вообще, процессный подход предполагает постоянное улучшение и стремление к бесконечной оптимизации компаний, поэтому перечислить все функциональные центры, работу которых можно улучшать на основе аналитики процессов этих центров – невозможно. Поэтому необходимо в первую очередь руководствоваться логикой и ориентироваться на специфику конкретной организации, здраво оценивая реальный потолок улучшения того или иного процесса. Улучшение ради улучшения не имеет никакого смысла с точки зрения повышения экономической эффективности. Индивидуальные особенности конкретного бизнеса гораздо лучше определят необходимость и правильный путь для оптимизации, чем шаблонные улучшения, пропитанные философией бесконечного повышения эффективности.
Автоматизация бизнес процессов как путь в будущее
Эра цифровой экономики дала бизнесу множество новых возможностей для повышения собственной процессной эффективности. Ведущие бизнес-аналитики активно трудились над разработкой темы процессного управления и оптимизации бизнес процессов в последние десять лет. Было разработано множество различных подходов и принципов управления компаниями, основанных на методике бизнес-процессов, и каждый из них заслуживает особого внимания. Они могут обладать разной степенью эффективности для конкретной компании, поскольку в какой-то мере зависят от вида бизнеса, масштаба и других характеристик экономики предприятия, но все они позволяют сделать вывод, что автоматизация бизнес процессов – это самый короткий путь к прогнозируемой модели управления и развития бизнеса.
На этом пути автоматизация бизнес процессов дает возможность повысить конкурентоспособность через увеличение продуктивности конкретного участка бизнес цепочки, облегчая ряд совершенно стандартных операционных процедур:
- Автоматизация упростит вопросы учета и отчетности, первичного бухгалтерского учета, ввода больших массивов информации, контроля товарных остатков и прочих математически/вычислительных процедур, которые традиционно являются преимущественно ручным блоком трудоемких операций. Чаще всего это достигается внедрением в практику использования автоматизированных IT-технологий, ориентированных на обработку документов и самостоятельное проведение операций, замены ввода данных на различные элементы сканирований и прочие упрощения таких рутинных процедур.
- Автоматизация процессов позволяет сократить или оптимизировать основные издержки предприятия. Основными расходными статьями традиционно являются производственный процесс и персонал компании, а автоматизация процессов даст возможность выделить основные узкие места и ключевые неэффективные звенья кадрового состава, а также добиться снижения расходов за счет исключения этих составляющих из операционной деятельности.
- Автоматизация процессов дает возможность повышать качество выпускаемой продукции за счет соблюдения нормативных требований и реализации мероприятий внутреннего контроля.
- Автоматизация процессов дает возможность высвободить интеллектуальный ресурс управленческого звена и ключевых специалистов компании, перенаправив их усилия с выполнения трудоемких и рутинных ручных операций на развитие компании.
Главный принцип любой автоматизации заключается в том, что она должна быть интегрирована на все уровни организационной структуры, связанные с данным (автоматизированным) бизнес-процессом. Нельзя автоматизировать процесс документооборота, не включив в него курьерскую службу компании и секретариат. Или, например, автоматизировать какой-либо цикл производственного процесса, но не автоматизировать вопросы логистики или работы с рекламациями клиентов. Если бухгалтеры продолжают считать платежки руками на калькуляторе, имея автоматизированный процесс согласования счетов и визирования оплаты, то бизнес процесс можно считать автоматизированным не полностью. А это, в какой-то мере, лишает его смысла вообще, потому что в случае возникновения ошибки (человеческий фактор), отследить ее вовремя не получиться, и она повлияет на последующие процессы.
Компании сталкиваются с разными сложностями при автоматизации бизнес процессов в зависимости от своих внутренних особенностей.
Например, ведение ручной бухгалтерии и разрозненного финансового учета табличного вида, по сути, тоже имеет определенное количество процессов внутри своей структуры, но внедрение комплексной автоматизации в это рабочее поле вызовет определенные проблемы, обусловленные не только техническими особенностями, но и противодействием со стороны персонала.
Поэтому проекты по автоматизации бизнес процессов почти всегда разрабатываются с нуля, так как невозможно, не погружаясь в специфику компании, определить те проблемы, которые могут всплыть в отдельно взятой организации. Случаются ситуации, когда менеджмент принимает решение об автоматизации, не приняв в расчет, что компания к ней попросту не готова, и реализовать проект не представляется возможным в принципе. Для того чтобы этого избежать, следует отчетливо представлять цель, которую необходимо достичь в результате автоматизации, определить, какие ресурсы нужны для достижения цели, какой персонал будет вовлечен в реализацию автоматизированного бизнес процесса, и какие рыночные тенденции могут оказать влияние на бизнес процесс в краткосрочной перспективе.
Только проработанная стратегия автоматизации процесса может обеспечить конечный результат и исключить риск работы ради работы. Всем известны примеры полной неработоспособности бизнес-процессов после их «автоматизации» или ситуации, когда невозможно завершить проекты по автоматизации из-за внутренних факторов. Поэтому немного остановимся на типичных проблемах, с которыми сталкиваются компании:
- Ошибки при переносе процесса в автоматизированную систему – самая частая проблема, вызванная желанием сэкономить. Неопытные менеджеры, чаще всего сами держатели процесса, пытаются перенести свою работу в информационное поле и автоматизировать. В результате – потеряны детали, нарушена или вообще не соблюдается логика, нет последовательности автоматических действий, а весь автоматизированный процесс можно назвать разве только «костылем». Это логичный результат, потому что профессионалы продаж не могут быть профессионалами в области построения автоматизированных бизнес процессов. Такая работа требует особой квалификации и опыта, а результат может быть достигнут только совместными усилиями узких специалистов и владельца процесса. Если речь идет о процессе распространяющимся за рамки одного подразделения или компания решила автоматизировать сложный процесс (закупочный, производственный и т.п.), то только квалифицированная команда способна детально исследовать процесс «как есть» и создать работоспособную автоматизированную схему.
- Саботаж автоматизации – это проблема, которая делит пальму первенства с ошибками при переносе процесса в автоматизированную систему. Команда, понимая, что автоматизированный процесс высвобождает у них временной ресурс, начинает мешать внедрению автоматизации, руководствуясь инстинктом самосохранения или элементарным нежеланием что-то менять в работе и учиться новому. Эту проблему достаточно сложно нивелировать на сто процентов, хотя при грамотном менеджменте и наличии реальных планов на ресурс в лице персонала, можно донести до команды, почему менеджмент принял решение об автоматизации, и какую роль в дальнейшем будет играть тот или иной специалист. Конечно, это не сработает, если ключевая цель автоматизации – сокращение издержек на персонал (а для многих компаний персонал по-прежнему остается самым дорогостоящим звеном).
- Техническая неподготовленность персонала – проблема, которая проявляется, как правило, либо в самом начале автоматизации, либо, наоборот, когда проект закончился и уже запущен. Вопрос торможения автоматизации в связи с техническими затруднениями, по сути, меньшее из зол, с которым можно столкнуться в этой сложной работе, поскольку всегда есть возможность произвести обучение персонала и создать в компании внутреннюю систему наставничества во избежание таких проблем в будущем.
- Не рассчитали свои силы – проблема инвестиционного характера. Планы на автоматизацию формулировались колоссальные, ресурсы компании были посчитаны неверно, и поэтому в какой-то момент стало очевидно, что на реализацию проекта не хватает ресурсов. Что делать? Оптимизировать сам процесс внедрения (время, скорость), искать ресурсы (заемные, отсрочки), менять условия (добиваться скидок, менять подрядчиков, сокращать объемы команд) и искать возможности для завершения процесса автоматизации любыми доступными способами, если он в итоге сулит компании прибыль.
Если указанные выше ошибки бизнесу удалось преодолеть, поскольку проблемные ситуации были проработаны заранее, перед ним встанет вопрос, как правильно отрегулировать автоматизированный бизнес процесс. Рассмотрим свойства таких бизнес-процессов поподробнее:
- Автоматизированный бизнес процесс должен обладать целью и задачами, которые компания решает в рамках этого бизнес процесса. Это значит, что любой пользователь процесса и менеджер компании, взглянув на бизнес процесс, может понять, какова конечная цель бизнес процесса, какие задачи необходимо выполнить, а также кто возьмет на себя ответственность за их выполнение на пути к этой цели. Например, если автоматизированный бизнес процесс – кросс-сейл товарных остатков прошлого года, то глобальная цель такого проекта заключается в том, чтобы распродать залежавшийся товар. Задачи на пути к достижению этой цели: формирование товарного ассортимента, написание скрипта на сайт, прикрепляющего товары по особому алгоритму в рекомендации покупателям, е-мейл рассылка по установленным правилам, установление скидок на товар прошлой коллекции и прочие действия, за каждым из которых закрепляется ответственный специалист или подразделение.
- Четкий автоматизированный процесс должен быть отрегулирован во времени. Это фактически главный принцип процессного управления: все действия и организация работы должна укладываться в какое-то регламентное время. Соответственно, говоря о первом примере с распродажей остатков, у такого проекта должен быть определен диапазон активности и скорость продуктивности. Диапазоном будет ограничено время начала работы и подведения результатов по процессу в целом, а скорость продуктивности (также измеряемая временем) даст возможность анализировать вклад каждого звена процесса в общий результат, контролируя при этом нарушение сроков исполнения работ, не обоснованное объективными причинами.
- Автоматизированный бизнес процесс должен иметь разделение на этапы и точки контроля. Это помогает контролировать ход выполнения процесса в зависимости от его стадии или фазы, распределять ответственность между участниками процесса и дополнительно оперативно анализировать процесс на этапе неполного завершения. Важно заметить, что внутри этапов команде предоставлена максимальная свобода действий и последовательности их активностей, но на точках контроля требуется жесткая отчетность по нормативному результату этапа и беспрекословное соблюдение назначенных сроков.
- Система нормативов автоматизированного бизнес процесса должна содержать достаточно сведений для возможности контролировать ход процесса. Процесс обязательно регламентируется набором документов и отчетностью. Совокупность этих элементов управления процессом позволяет команде искать выходы из затруднительных ситуаций в рамках установленного поля, а не просто следуя инструкции.
- Автоматизированный бизнес процесс можно рассмотреть не только с точки зрения указанных ранее аспектов, но и в разрезе используемых для его реализации ресурсов: рабочих часов, финансов, оборудования, технологий и прочего. Все эти вопросы должны быть изначально продуманы и рассмотрены на этапе внедрения бизнес процесса с учетом неких прогностических изменений ситуации, чтобы гарантировать завершение бизнес-процесса запланированным результатом.
- Ответственные за исполнение и результативность бизнес процесса люди. Насколько бы ни была совершенной система автоматизации бизнес-процессов, ей нужен живой контролер, способный смотреть на ситуацию глобально и критически. Поэтому любой автоматизированный бизнес процесс должен быть обеспечен ответственными за его исполнение сотрудниками, задача которых заключается не только в предметной функции, но и в контроле ключевых точек процесса.
- Информирование участников – важнейший элемент взаимосвязанной системы бизнес процессов, который является также и инструментом контроля. Наибольшую продуктивность показывают системы автоматического информирования обо всех происходящих в бизнес процессе действиях, построенные по принципу точек, на которых система сама генерирует уведомления и информирует особый список участников. Конечно, ручное информирование тоже работает, но требует дисциплины и очень часто дает определенные сбои.
Исходя из вышеперечисленного, очевидно, что автоматизация бизнес процессов, вне зависимости от локации, отрасли, рынка или направления бизнеса, то есть для любой компании – это принципиально новый уровень ведения бизнеса. Переоценить выгоды от внедрения автоматизированных бизнес-процессов невозможно, поскольку в эпоху жесточайшей конкуренции и цифровой экономики они становятся абсолютной необходимостью для тех компаний, которые хотят сохранить и приумножить свою долю рынка. Внедряя у себя автоматизированные бизнес процессы, компания не просто получает в свой актив определенный набор очевидных преимуществ по сравнению с конкурентами, она выводит свой бизнес на принципиально новый уровень ведения бизнеса. Отчасти этот процесс можно назвать мировоззрением, ориентированным на внутреннюю результативность и повышение эффективности. В двадцать первом веке ручной труд больше не является основой экономики, и компании могут ускорить свое развитие, увеличить продуктивность и скорость своей работы, улучшить показатели качества обслуживания или снизить затраты за счет интеллектуальных достижений человечества в области автоматизации бизнес-процессов.
Статья предназначена для практикующих бизнес-аналитиков и консультантов в области проектирования бизнес-процессов.
На сегодняшний день все больше ИТ-подразделений крупных и средних организаций заняты составлением моделей своих бизнес-процессов в рамках представления ИТ-услуг. Эта задача определяется ими среди важнейших.
В этой статье мы предлагаем обсудить два подхода к описанию бизнес-процессов ИТ-подразделения в рамках предоставления ими ИТ-услуг. Надеемся, что изложенная здесь информация поможет читателю выбрать оптимальную модель при описании бизнес-процессов, позволяющую достичь поставленных целей.
Для наглядности описания и сравнения предложенных подходов рассмотрим следующий пример. Подразделение – пользователь ИТ-услуг обращается в ИТ-подразделение за услугой и получает ее (отметим, что мы не претендуем на полноту отражения всех процессов в данных схемах).
Обратим внимание, что четко просматривается последовательность выполнения функций процесса, от его начала процесса до завершения.
Тот же самый процесс описан с использованием другого подхода. На вход поступает информация, и в зависимости от ее типа, запускаются конкретные цепочки процедур. Здесь труднее увидеть последовательность всех этапов течения бизнес-процесса. Зато хорошо заметно, что описанная информация более формализована и типизирована.
Итак, опишем подробнее показанные подходы.
Первый подход . Это наиболее стандартный подход, очень часто используемый во многих организациях, при котором в рамках течения процесса отображается последовательность исполнения функций.
Возможно, в организации уже используется в той или иной мере процессный подход к описанию и организации деятельности всего предприятия, и существует или выбрана определенная методология описания бизнес-процессов. Скорее всего, это методология имеет в своей основе именно первый подход.
Тогда становится важным описать деятельность ИТ-подразделения на основе принятой методологии для однообразного восприятия всех процессов организации.
Отметим также, что при данном подходе хорошо просматривается стадийность этапов процессов, в том числе и при взаимодействии с процессами других подразделений.
Используя этот подход, мы видим и описываем процессы сверху. Стоит отметить, что данный подход в полной мере соответствует методологии процессного подхода в управлении.
Если же в дальнейшем подразумевается автоматизация процессов ИТ-подразделения имеет смысл описывать их, используя второй подход . Почему? Во-первых, второй подход содержит бОльшую формализацию потоков данных, которые можно типизировать и стандартизировать, и затем автоматизировать. В результате получается хорошая основа для наложения системы автоматизации.
Во-вторых, в случае этого подхода взгляд на бизнес-процессы ИТ-подразделения – со стороны самого ИТ-подразделения, т.е. изнутри. Вы находитесь внутри механизма. На вход поступают потоки данных, для их обработки запускаются вполне конкретные соответствующие цепочки процедур и функций, на выход подается продукт, соответствующий установленным нормам.
Даже, если пока не затрагивать автоматизацию бизнес-процессов, второй подход к описанию бизнес-процессов предоставляет руководству ИТ-подразделения массу интересных возможностей для решения управленческих задач.
При решении задачи обеспечения качественного функционирования бизнес-процессов ИТ-подразделения, когда важно обеспечить рациональную и эффективную обработку поступающих данных, необходима достаточно серьезная формализация бизнес-процессов подразделения. Второй подход позволяет наилучшим, на наш взгляд, образом отразить типизацию, классификацию входящих и исходящих данных, соответствующие процедуры их обработки внутри подразделения, наметить точки контроля и оценить процедуры получения значений показателей в этих точках. А, следовательно, предоставляет возможность руководству эффективнее анализировать распределение и использование ресурсов подразделения на предмет их рациональности и продуктивности, сокращения издержек, управления и контроля.
Если Директор ИТ будет иметь у себя оба описания, это будет очень полезно.
Первый способ позволит рассматривать процессы ИТ-подразделения на основе принятой в компании и понятной топ-менеджменту организации методологии, позволит Директору ИТ увидеть свое подразделение во взаимодействии с другими подразделениями внутри компании. Этот способ приемлем для описания процессов «как есть» и «как будет».
Второй способ будет труден, скорее всего, для прочтения и понимания топ-менеджменту организации, однако окажется весьма полезен Директору ИТ. Подразумевая бОльшую формализацию данных, он более применим для описания процессов «как будет». На наш взгляд, этот подход позволит Директору ИТ более эффективно оценивать ресурсы и процессы ИТ-подразделения и управлять ими с целью повышения качества предоставляемых ИТ-услуг.
Человек в течение всей истории своего развития старался всячески улучшить условия своего существования. Для этого он, используя свой труд, создавал блага, которые бы обеспечивали его едой, жилищем и другими жизненно важными атрибутами. Тем не менее очевиден факт, что данные новшества со временем морально и физически устаревали, и именно это давало толчок к созданию чего-то кардинально иного. Так, например, создав лук, люди успешно использовали его в военных действиях в течение веков. Однако возросшие потребности военного дела требовали пересмотра существующего арсенала, и так в X веке в Китае появилось первое огнестрельное оружие. Постоянно меняющаяся конъюнктура требовала от человека немедленной реакции в форме изобретения новшеств, что могло бы существенно увеличить его эффективность в тех или иных условиях. С появлением ЭВМ в 50-х годах прошлого столетия мир получил возможность накапливать, обрабатывать и передавать информацию, закодированную в цифровом формате. С развитием технологий, позволяющих таким образом работать с данными, существенно стали увеличиваться объемы информации, которые могли бы быть накоплены, обработаны или переданы. Именно развитие информационных технологий позволяет клиенту банка осуществить перевод денежных средств в дочерний офис на другом конце света за считанные минуты, сотруднику отдела продаж осуществить поиск в массиве данных необходимой информации о клиенте в кратчайшие сроки и банкам, не прибегая к печати банкнот, хранить сотни миллиардов долларов в безналичной форме. Информационные технологии предоставляют возможность экономическим агентам эффективно использовать информацию как фактор производства, увеличив свою производительность. 1.1.Этапы развития общества: от аграрного к информационному Сегодня экспертами принято выделять четыре основных этапа развития общественного порядка: . Аграрное общество; . Индустриальное общество; . Постиндустриальное общество; . Информационное общество; Суть аграрного общества заключается в зависимости от земли как фактора производства, причем первичный сектор является основным для экономической системы данного типа. Таким образом, общественное устройство аграрного типа характеризуется доминирующей ролью сельского хозяйства. До промышленной революции, начавшейся в конце XVIII века, аграрное общество являлось единственной формой общественного строя, что и обуславливало относительно низкие темпы экономического роста в сравнении с двумя последними веками, так как ориентация на ручной труд, отсутствие технологий, сравнительно низкий темп научного развития не позволяли развиваться мировой экономике так стремительно, как это происходит на современном этапе. Низкая социальная дифференциация, являющаяся характерной чертой аграрного общества, подчеркивала сложность самостоятельного накопления больших объемов капитала. Тем не менее, общество, особенное европейское, быстро развивалось. Увеличение объемов торговли, развитие финансовых институтов, науки и факторных рынков способствовали росту спроса на продукцию массового производства, что в результате привело к переходу от ручного труда к машинному типу производства. Данный период характеризуется высоким уровнем экономического роста, урбанизацией, изменениями в общественной структуре и развитием в таких областях как текстильная промышленность, металлургия, транспорт и связь. Индустриальное общество в отличие от аграрного связывают с преобладающей долей вторичного сектора экономики, который включает в себя обрабатывающую промышленность и строительство. Как известно, существует три сектора экономической деятельности: вышеупомянутые первичный и вторичный, представляющие собой сельское хозяйство, добывающую промышленность и обрабатывающую промышленность, строительство соответственно, а также третичный сектор, включающий в себя сферу услуг. На определенном этапе развития общество в состоянии полностью удовлетворить спрос населения на товарную продукцию. Уровень жизн
Журнал «Корпоративные системы», июль-август 2007г, Киев
Роль IT -подразделения в описании бизнес-процессов компании
Качественное описание бизнес-процессов основывается на графическом моделировании. Это бесспорно информационная технология и прогрессивные IT-подразделения могут и должны внедрять ее в своих компаниях. Сейчас перед IT-подразделениями стоит задача не только оказывать IT-услуги своим компаниям, но и участвовать в достижении бизнес-результатов. Эта идея уже лет 7 активно обсуждается и реализуется западными IT-менеджерами. Они уверены, что IT-специалисты могут не только моделировать бизнес-процессы компании, но и участвовать в их анализе и оптимизации, привнося свое уникальное видение в методы ведения бизнеса. IT и бизнес — одна команда, и чем слаженней они будут работать, тем лучше будут совместные результаты.
Идея и необходимость описания бизнес-процессов
Для описания бизнес-процессов компании существует множество Case-средств, которые позволяют формировать модели и процессные регламенты, и что не маловажно, легко и быстро вносить в них изменения. Изначально, Case-средства были созданы для постановки задач и проектирования ИС, а сейчас они используются в целях регламентации деятельности компании, оптимизации бизнес-процессов и построения информационной архитектуры компании. Поэтому не редко бывает, что проект по описанию бизнес-процессов в компании инициирует IT директор.
Из личного опыта: Когда я работала системным аналитиком в отделе автоматизации крупного холдинга, именно IT директор организовал для топ-менеджеров мини-семинар по рассмотрению деятельности компании через бизнес-процессы (и это было 3 года назад). Так же, он обучал сотрудников своего отдела методикам моделирования бизнес-процессов, инициировал проекты по описанию бизнес-процессов не только для целей автоматизации, но и для реорганизации отдельных компаний и подразделений холдинга. На это его вдохновило обучение на MBA. Фактически, IT-директор выполнял функции руководителя IT-подразделения и CIO холдинга.
Иногда идеей описания бизнес-процессов компания «заражается» через собственников или топ-менежмент. Например, генеральный директор прочел интересную статью о пользе бизнес-процессов или услышал об этом от своих коллег — и вот он срочно запускает проект по описанию бизнес-процессов компании.
Подготовка компании к проекту по описанию бизнес-процессов
Итак, вы IT-директор или скромный руководитель IT-подразделения и вы со своими подчиненными участвуете в проекте по описанию бизнес-процессов, который затеял один из топ-менеджеров компании, или вы сами. С чего начать и как подготовить компанию к такому проекту? Вот четыре составляющие, без которых проект начинать нельзя: цель, обучение, команда, план.
Цель
Возможные цели проекта по описанию бизнес-процессов — это структуризация и регламентация компании, тиражирование бизнеса, оптимизация бизнес-процессов, внедрение СМК ИСО, функционально-стоимостной анализ деятельности компании, проектирование и внедрение ИС и т. д. Однако это очень общие формулировки, чтобы в конце проекта оценить, насколько вы достигли своей цели. Например, если ваша цель описать бизнес-процессы для тиражирования бизнеса, то ее можно детализировать как выделение основных бизнес-процессов компании XXX и разработка процессных регламентов. Для тиражирования бизнеса надо разработать еще ряд документов, но вы ограничили свой проект с помощью цели и можете точно сказать, что когда процессные регламенты выделенных бизнес-процессов разработаны, ваш проект успешно завершен. Процессные регламенты включают в себя графическую модель бизнес-процесса, ее текстовое описание, перечень поставщиков и клиентов бизнес-процесса, входы, выходы и параметры бизнес-процесса и т. д. В своем проекте вы можете ограничиться только разработкой моделей бизнес-процессов, тогда именно это и запишите в цель проекта: выделение бизнес-процессов компании ХХХ и разработка графических моделей.
Еще одним хорошим вариантом конкретизации цели проекта является присутствие в формулировке цели название бизнес-процесса или бизнес-процессов для описания. Например, разработка модели и регламента бизнес-процесса закупки и поставки сырья на склад.
Обучение
Следующий шаг — это обучение. Однако для проекта по описанию бизнес-процессов обучать нужно не только аналитиков, которые будут моделировать, но и топ-менеджеров и среднее управленческое звено и ключевых сотрудников компании, которые будут использовать эти описания. Если вы описали бизнес-процессы, но это не используется в компании, то ваш проект неудачен, он не принес никакой пользы, и компания зря потратила на него свои деньги. Обучать всех выше перечисленных сотрудников компании нужно различным вещам. Для топ-менеджеров необходимо продемонстрировать, что такое бизнес-процессы и процессный подход к управлению, каких организационных эффектов можно достичь с их помощью. Среднее управленческое звено и ключевые сотрудники должны понимать, сущность бизнес-процессов, знать методы их анализа и оптимизации, а так же разбираться в моделях бизнес-процессов, которые будут разрабатывать аналитики. И аналитиков в свою очередь надо тренировать использованию технологий сбора информации, интерпретации и моделирования. (рис.1).
Обучение помогает сформировать понимание проекта и его необходимость не только у инициаторов проекта, но и у всей компании. В ходе обучения вы можете уточнить цели проекта, найти сторонников и сформировать команду.
Команда
Формирование команды проекта — это еще один важный и необходимый шаг перед началом работ. Давайте обсудим, кто должен войти в рабочую группу проекта, и какие роли в этой группе могут выполнять IT-специалисты. (рис 2).
Основной фигурой, которая может не входить в рабочую группу, но должна обязательно быть обозначенной — Заказчик проекта. Это человек, которому нужно описание бизнес-процессов и он обязательно должен иметь соответствующие полномочия и ресурсы для проведения работ. Заказчиком может выступать владелец бизнеса или топ-менеджер (директор, зам. директора, руководитель функционального направления). Даже если бизнес-процессы описываются для постановки задачи к ИС, то Заказчиком этого описания должен выступать топ-менеджер, заказывающий ИС. Зачастую руководители IT-подразделений берут в этой ситуации функции Заказчика на себя, но они не всегда имеют соответствующие полномочия и ресурсы: участники описываемых бизнес-процессов не уделяют достаточно времени на проект, согласование моделей затягивается или вообще не выполняется.
Возглавляет рабочую группу Руководитель проекта — он организует и координирует проект, работает с Заказчиком и отвечает за результаты проекта. Руководителем проекта должен быть один из топ-менеджеров компании. Если руководитель IT-подразделения имеет статус IT-директора и входит в топ-менежмент компании — то Руководителем проекта может быть он.
Работу по сбору информации, формированию моделей и разработке процессных регламентов выполняют Аналитики проекта. С этой функцией лучше всего справляются IT-специалисты или люди с подобного рода образованием, потому что они владеют Case-средствами (или могут быстро их освоить), а так же имеют опыт разработки алгоритмов и схем. Хорошими Аналитиками становятся и те сотрудники компании, которые в своей деятельности, так или иначе, сталкиваются с анализом или регламентацией деятельности компании — это сотрудники отделов планирования и анализа, менеджеры по качеству и т. д.
Когда в проекте работает несколько Аналитиков, то параллельно они могут описывать разные процессы и работать на разных уровнях декомпозиции описания. Для того чтобы модели Аналитиков не пересекались и имели одинаковую подробность в рабочей группе проекта должен присутствовать Интергатор. Он удерживает целостность бизнес-модели компании и координирует работу Аналитиков. Чаще всего функции Интегратора выполняет один из Аналитиков или сам Руководитель проекта, если он имеет соответствующие компетенции.
Секретарь рабочей группы — не очень большая, но ответственная роль. Он организует заседания рабочей группы, фиксирует принимаемые решения и контролирует их исполнения. Фактически он является помощником Руководителя проекта, его левой рукой и «контрольным» органом. В роли секретаря должен быть высокоорганизованный, ответственный, исполнительный человек и некоторые IT-специалисты обладают такими качествами.
И вот мы добрались до тех ролей, которые IT-специалисты выполнять ни как не могут (конечно, если мы не описываем бизнес-процессы IT компании). В процессном подходе к управлению для каждого бизнес-процесса выделяют Владельца — это сотрудник компании, который управляет бизнес-процессом, имеет в своем распоряжении ресурсы и отвечает за результат бизнес-процесса. Если вы описываете бизнес-процесс в рамках одного подразделения компании, то руководитель этого подразделения скорей всего и будет Владельцем бизнес-процесса. Например, владельцем бизнес-процесса закупки и поставки сырья на склад, который мы собирались описывать, будет руководитель отдела закупок. Он должен отвечать за результат этого бизнес-процесса — а именно, своевременную поставку необходимого сырья на склад. Однако если бизнес-процесс сквозной и охватывает несколько подразделений — то тут уже на рабочую группу надо привлекать всех участвующих в процессе руководителей подразделений и кого-то из топ-менеджеров. Владельцем такого бизнес-процесса будет топ-менеджер или один из руководителей подразделений. Например, в компании есть транспортный отдел, который обеспечивает доставку сырья на склад. Тогда в бизнес-процессе закупки и поставки сырья на склад участвуют два подразделения: отдел закупок и транспортный отдел. Владельцем бизнес-процесса можно назначить зам.директора по закупкам (на больших предприятиях есть и такие) или руководителя отдела закупок.
Если вы не внедряете процессный подход к управлению в своей компании, то функция Владельца процесса сводится к ответственности за достоверность описания бизнес-процесса.
Так же, для описания бизнес-процессов необходимо привлекать их участников и непосредственных исполнителей. Поэтому в рабочую группу проекта должны войти Эксперты — ключевые сотрудники компании, которые участвуют в бизнес-процессах. Например, ведущий специалист по продажам, мастер смены. Для Аналитиков Владельцы и Эксперты являются основным источником информации о бизнес-процессах, они проверяют модели бизнес-процессов на соответствие действительности и утверждают их.
Когда компания не готова реализовать проект по описанию бизнес-процессов самостоятельно ей на помощь приходят Консультанты. Они проводят обучение и организуют проектную работу. Консультанты берут на себя описание бизнес-процессов и выступают в роли Аналитиков и Интергаторов. Однако в последнее время, Консультантов чаще всего приглашают для организации пилотных проектов по описанию нескольких бизнес-процессов компании. В ходе таких проектов сотрудники компании работают вместе с Консультантами и получают необходимые навыки для реализации последующих проектов самостоятельно. В дальнейшем Консультанты оказывают сотрудникам компании методическую поддержку и экспертируют их самостоятельную работу.
План
И последний шаг в подготовке проекта по описанию бизнес-процессов — это планирование. Сначала определяется структура работ, исполнители и необходимые трудозатраты. Затем делается календарная привязка и определяется длительность работ: в плане учитываются праздники, дни рождения боса, корпоративные выезды и командировки. К примеру, вам на согласование модели бизнес-процесса надо всего-то 3 часа. С этой целью вы запланировали 2 встречи с Владельцем и Экспертами этого бизнес-процесса с перерывом в два дня. Длительность работ по согласованию модели бизнес-процесса составит 4 дня, но если в этот период Владелец бизнес-процесса уедет в командировку или возьмет несколько отгулов на празднование своего дня рождения, то длительность работ может существенно увеличится. Конечно, помимо запланированных, бывают и «внезапные» командировки, а для этого между работами проекта оставляется временной лаг. Это означает, что если длительность работ по согласованию модели бизнес-процесса составляет 4 дня, то перед началом следующей работы по формирование структуры процессного регламента надо оставить 1 резервный день. (рис.3). Когда такие лаги выставлены по всему проекту, то даже незапланированное отсутствие кого-то из участников проекта не повлияет на суммарную длительность проекта.
Еще один важный момент планирования проекта по описанию бизнес-процессов, это загрузка участников проекта. Помимо работы в проекте, его участники продолжают выполнять функциональные обязанности в компании. Особенно это касается Владельцев и Экспертов бизнес-процессов. Их загрузка в проекте редко может превышать 5 часов в неделю и это необходимо учитывать при определении длительности работ.
Бизнес-результаты проекта по описанию процессов компании
«Если раньше IT оценивались исключительно по тому, насколько успешно они осуществляли технологические проекты, то в последующие пять лет они будут оцениваться по тому, насколько сами эти проекты помогают бизнесу в его деятельности». Это было написано в журнале CIO Magazine еще вначале 2000-х. Время оценивать работу IT-подразделений по бизнес-результатам пришло. Проект по описанию бизнес-процессов несомненно поможет бизнесу в его деятельности и будет способствовать:
- повышению прозрачности деятельности компании;
- закреплению зон ответственности сотрудников компании;
- улучшению взаимодействия подразделений;
- решению проблемы «незаменимых сотрудников».
И если проект по описанию бизнес-процессов компании инициирует IT-подразделение, то достичь перечисленных результатов оно может только в тесном сотрудничестве и взаимопонимании с бизнесом. По этому поводу хорошее выражение присутствовало в выступлении Эдуарда Савушкина (корпорация Инком) на съезде IT-директоров 2007 г в Киеве: не бывает IT-проектов, бывают бизнес-проекты с вовлечением IT.
Концепция управления качеством информационных услуг (Information Technology Service Management - ITSM) возникла в результате принципиального изменения сегодняшней роли ИТ-подразделений. Бизнес-процессы настолько тесно увязаны с приложениями, техническими ресурсами и деятельностью персонала отделов автоматизации, что эффективность последних оказывается одним из решающих факторов эффективности компании в целом.
Сами информационные технологии, на которые опирается компания в повседневной работе, постоянно усложняются, корпоративная инфраструктура растет и требует значительных усилий для своего поддержания в работоспособном состоянии. А бизнес-подразделения хотят, чтобы ИТ-механизмы работали как часы, обслуживая их с надлежащим качеством и при оптимальных затратах.
Основная идея внедрения ITSM состоит в том, чтобы ИТ-отдел перестал быть вспомогательным элементом для основного бизнеса компании, ответственным только за работу отдельных серверов, сетей и приложений, «где-то и как-то» применяющихся в компании. Отдел автоматизации становится полноправным участником бизнеса, выступая в роли поставщика определенных услуг для бизнес-подразделений, а отношения между ними формализуются как отношения «поставщик услуг - потребитель услуг«. Бизнес-подразделение формулирует свои требования к необходимому спектру услуг и их качеству, руководство компании определяет объем финансирования для выполнения этих требований, а подразделения автоматизации поддерживают и развивают информационную инфраструктуру компании таким образом, чтобы она была в состоянии обеспечить запрошенную услугу с заданным качеством.
Для того чтобы сделать явью эту идеальную картинку, необходимо научить ИТ-отделы работать по-новому, перейти от управления отдельными информационными ресурсами компании к управлению услугами, которые на этих ресурсах базируются. Перестать воспринимать персонал других отделов только как своих пользователей, наладить отношениями с ними как с заказчиками.
Скажем, бухгалтерия хочет иметь автоматизированный процесс выставления счетов, что, с точки зрения ИТ-отдела услуга, которая будет реализована при помощи некоторой совокупности ПК, сервера, приложений и сети, будет обладать определенными характеристиками надежности, производительности, времени отклика, а предоставление этой услуги будет контролироваться, по результатам контроля будут сформированы отчеты в понятных заказчику бухгалтерских терминах. Эта услуга будет обладать, наконец, определенной себестоимостью, зависящей от надежности, производительности и, возможно, других характеристик. Значит, заказчик будет иметь представление о том, какие расходы повлечет за собой нужное ему качество услуги, и, можно надеяться, выдвинет ИТ-отделу реальные требования, а тот, в свою очередь, сможет организовать свою работу, исходя из реальных приоритетов.
Итак, ITSM подразумевает коренную реорганизацию службы эксплуатации информационных технологий. Опираясь на мировой опыт, компания Нewlett-Рackard разработала типовую модель управления качеством информационных услуг, так называемую ITSM Reference Model. Модель детально описывает процессы и взаимосвязи между ними, которые должен поддерживать ИТ-отдел, чтобы предоставлять информационные услуги с гарантированным качеством.
Ключевые элементы ITSM - процессы, персонал, технологии
Идеология ITSM держится на трех китах:
- формализация процессов функционирования информационных технологий;
- профессионализм и четкая ответственность сотрудников ИТ-отдела за определенный круг задач;
- технологическая инфраструктура обеспечения качества услуг: собственно информационные технологии, служба поддержки пользователей, служба управления конфигурациями и изменениями, система контроля услуг, служба тестирования и внедрения новых услуг и т.д.
Решающим для успеха внедрения ITSM является первый элемент - разработка производственных процессов ИТ-отдела, определяющих последовательность действий персонала в определенных ситуациях, координирующих работу всех сотрудников, служб и подразделений автоматизации. ИТ-отделы постоянно внедряют новые технологии, еще более усложняющие информационную инфраструктуру компании. Однако более эффективные системы сами по себе не обеспечат бизнес необходимыми услугами с требуемым качеством, если не определены процессы использования таких систем.
Типичные примеры ИТ-процессов - установка нового ПО, ликвидация проблем в сети, процесс перехода на новую резервную систему и т.д. Нечетко определенные и недокументированные процессы неизбежно станут источником незапланированных и, следовательно, неконтролируемых изменений в ИТ-инфраструктуре. Это приведет к большому числу переделок, дублированию функций, периодическим простоям и в конечном итоге к нерациональному использованию ресурсов, увеличению времени восстановления после сбоев и недовольству пользователей. А для бизнеса компании в целом, особенно если он уже успел обзавестись приставкой «е», последствия могут оказаться просто катастрофическими. Так, например, случилось с крупнейшим интерактивным аукционом eBay, который почти сутки находился в нерабочем состоянии из-за проблем с программным обеспечением. Это сразу почувствовали его клиенты во всем мире, а акции eBay подешевели суммарно на 5 млрд. долл., зато заработали конкуренты, ведь расстояние до конкурента на электронном рынке равно одному щелчку клавиши мыши.
Если для ИТ-процесса четко не сформулированы условия начала его выполнения, ИТ-отдел не сможет гарантировать, что соответствующая услуга будет предоставляться из раза в раз с неизменным качеством. Это, в свою очередь, повлияет на бизнес-процессы компании. Отрицательное влияние на эффективность бизнеса может оказать и отсутствие четко определенных взаимосвязей между процессами.
Поэтому важнейшая составляющая реализации ITSM - разработка формализованных процессов ИТ-отдела. Для каждого процесса определяется последовательность выполнения работ, необходимые ресурсы и затраты времени, средства автоматизации и контроля качества. Детальная проработка каждого ИТ-процесса в отдельности и всех ИТ-процессов вместе обеспечит согласованную работу бизнес-подразделений и служб автоматизации.
Кроме того, если процесс четко определен и документирован, включая входные параметры и результаты выполнения, можно измерить его производительность. Это особенно важно, если перед ИТ-отделом стоит задача реализации услуги заданного качества за определенную стоимость. Кроме того, это позволит совершенствовать процесс и вносить необходимые изменения в упреждающем режиме - еще до того, как произошел сбой в реализации услуги.
Внедрение процессной организации функционирования инженерных технологий приведет к изменению структуры ИТ-отдела, поскольку процесс задействует определенных людей, и их обязанности должны быть также определены и документированы, как и другие элементы любого процесса.
Особую роль играет менеджер процесса - Process Owner - сотрудник, который будет контролировать выполнение процесса от начала и до конца. Его обязанности и полномочия должны быть определены и подтверждены руководством компании, поскольку менеджеру процесса придется принимать решения, затрагивающие разные подразделения. Ведь ИТ-процесс, как правило, является кросс-функциональным и пересекает организационные границы. Когда в компании развертывается новое приложение или происходит модернизация сервера, директивы менеджера такого процесса обязаны выполнять сотрудники любых отделов, которых коснутся изменения информационной инфраструктуры. Менеджер процесса назначает ответственных за определенные задачи, анализирует влияние процесса на функционирование бизнеса компании, поддерживает взаимоотношения с менеджерами других подразделений. Для ИТ-отделов, которые привыкли распределять ответственность персонала по функциональным группам ресурсов и не имеют общего видения процессов, реорганизация работы, связанная с определением процесса и его менеджера, необходима, но и наиболее сложна.
Назначение менеджера процесса - один из элементов управления ИТ-услугами в целом. Другие характеристики управления процессами включают формализацию, повышение эффективности процесса и устранение причин неправильной работы, разработку и документирование процесса, контроль за тем, чтобы процесс соответствовал требованиям пользователей, а его результаты - заданным спецификациям.
Типовая модель
Два года назад Hewlett-Packard предложила типовую модель информационных технологий HP IT Reference Model, которая позволяет разработать структуру ИТ-процессов в компании и на ее основе реализовать управление качеством информационных услуг. Типовая модель представляет собой методику внедрения лучшего международного опыта в области ИТ, собранного в Библиотеке IT Infrastructure Library. Библиотека ITIL - это сборник из 68 книг по различным областям функционирования ИТ, включая планирование ресурсов, управление проблемами, управление инцидентами, разработку и внедрение новых услуг, снижение расходов, управление пользователями и т.д. Эта информация собиралась и систематизировалась Комитетом по телекоммуникациям при правительстве Великобритании, а сейчас поддерживается, издается и обновляется независимой организацией EXIN .
Библиотека ITIL - своеобразный эталон, сопоставляя с которым состояние информационных технологий компании можно определять области, требующие усовершенствования. НР взяла систему стандартов ITIL за основу и, добавив собственный опыт, а также опыт своих партнеров и заказчиков, разработала структуру ИТ-процессов и их взаимосвязей. Если Библиотека ITIL показывает, «что такое хорошо», то Типовая модель определяет пути достижения эталона. Типовая модель - самый верхний уровень системы управления качеством информационных услуг, карта стандартных ИТ-процессов, которая при внедрении в конкретной оргагнизации наполняется специфическим содержанием, позволяет распределить необходимые функциональные роли между сотрудниками ИТ-отдела и выбрать оптимальный инструментарий. НР подчеркивает, что разработанная модель применима к любой информационной инфраструктуре, независимо от ее масштаба и степени распределенности.
Типовая модель ИТ отображает жизненный цикл большинства услуг, которые ИТ-отдел может предоставлять бизнес-подразделениям компании. Прежде всего, она позволяет оценить текущее состояние информационной инфраструктуры, определить статус, значимость и взаимосвязи уже реализованных процессов. Благодаря этому ИТ-отдел поймет, какие процессы требуют переработки, каких процессов не хватает, каким он видит организацию ИТ-услуг в идеале и как спланировать достижение поставленных целей. Делая акцент на взаимосвязи между процессами, Типовая модель позволяет выделить приоритеты в реализации процессов. Определение зависимостей между процессами дает возможность выявить ту информацию, которая будет ими совместно использоваться, и тем самым упрощает разработку процессов. Типовая модель может стать отправной точкой для организационных изменений в работе ИТ-отдела. Работа с Типовой моделью и анализ процессов позволяет выявить потенциальные области применения технологий управления. Кроме того, ее использование даст возможность понять, какие информационные услуги ИТ-отдел должен обеспечивать внутренними силами, а где есть потенциал для аутсорсинга - передачи части функций сторонним организациям, и как внутренние процессы будут взаимодействовать с услугами от внешнего поставщика.
В Типовой модели НР все процессы разделены на пять групп, каждая из которых отражает определенный аспект жизненного цикла ИТ-услуги (рис.) - от анализа бизнес-задач, стоящих перед отделом автоматизации, до определения спецификаций услуги и разработки соглашений об уровне обслуживания, реализации, развертывания и поддержки услуг.
Гарантии предоставления услуг
Процессы этой группы занимают центральное место в структуре управления ИТ-услугами. Во-первых, они обеспечивают необходимую стабильность ИТ-среды. Во-вторых, с ними так или иначе взаимодействуют все остальные процессы.
Процесс управления изменениями (change management) регистрирует все изменения корпоративной информационной среды, координирует заявки на проведение работ, связанных с внесением изменений, устанавливает приоритеты для запросов на изменения, определяет полномочия на внесение изменений в работающую систему, распределяет ресурсы, координирует восстановление при сбоях в результате изменений и оценивает риски и влияние любых изменений на информационную среду. И поскольку любой процесс в представленной модели так или иначе вызывает изменения информационной инфраструктуры, он неизбежно взаимодействует с процессом управления изменениями - единственным в структуре ИТ-процессов, который регламентирует, контролирует и фиксирует изменения и тем самым обеспечивает устойчивое состояние информационной среды.
Процесс управления конфигурациями (configuration management) регистрирует и контролирует данные об ИТ-инфраструктуре. Этот процесс обрабатывает информацию о каждом элементе конфигурации (configuration item - CI): атрибуты CI (системы и сетевые устройства, прикладные программы, персонал, документация и т.д.), статус CI (в наличии, в ремонте, в производственной среде и т.д.) и взаимосвязи между ними (например, «компьютер А находится на рабочем столе пользователя X», «принтеры В, C и D доступны для использования» и т.д.). Процесс управления конфигурацией, который относится только к ресурсам ИТ-инфраструктуры, не следует путать со стандартной процедурой управления ресурсами предприятия. Любые процессы, влияющие на инфраструктуру (а это все процессы модели), будут взаимодействовать с процессом управления конфигурацией.
Привязка ИТ к бизнес-процессам
Процессы этой группы имеют стратегическое значение, поскольку обеспечивают ИТ-отделу возможность работать «как бизнес», а не «для бизнеса». Здесь анализируется потенциальный рынок услуг и возможная конкуренция, достигается взаимопонимание между ИТ-отделом и его заказчиками в отношении потребностей бизнеса и возможностей информационной инфраструктуры и, наконец, формулируется стратегия ИТ-отдела по оптимальному в смысле задействованных ресурсов способу предоставления информационных услуг.
В ходе анализа бизнес-процессов (business assessment) исследуется рынок ИТ-услуг и определяются бизнес-требования к ИТ-отделу. Процесс управления пользователями (customer management) позволяет ИТ-отделу выступить в роли полноправного бизнес-партнера для потребителей информационных услуг. Управление пользователями - это возможность прогнозировать их потребности, продавать ИТ-услуги, измерять степень удовлетворенности заказчика предоставленной ему услугой. Процесс управления пользователями взаимодействует с другими процессами «бизнес-группы». Информация о пользователях, полученная в ходе выполнения этого процесса, может использоваться при анализе рынка и конкурентной ситуации, а результаты анализа бизнес-процессов и данные о пользователях в свою очередь являются основой для разработки ИТ-стратегии.
Ключевое значение для ITSM имеет процесс разработки ИТ-стратегии (IT strategy development). Используя данные процессов бизнес-анализа и управления пользователями, этот процесс трансформирует требования бизнеса в цели и задачи ИТ-отдела и планы их достижения. Разработка ИТ-стратегии включает определение бюджета ИТ-отдела, документальное закрепление общего видения ИТ-процессов и услуг, описание этапов реализации поставленных задач, определение ключевых условий их достижения и возможных проблем, выбор архитектуры информационной среды и необходимых технологий, а также, возможно, принятие решения о структурной реорганизации ИТ-отдела.
Управление услугами
Процессы этой группы преобразуют общее видение информационных услуг, ИТ-стратегию, в определение конкретных услуг с помощью детальных спецификаций. Процессы управления услугами определяют уровни предоставляемых услуг, поддерживают заключение соглашений об уровне обслуживания (service level agreement, SLА), обеспечивают защиту инфраструктуры и данных. Процессы управления услугами позволяют получить информацию о доступности услуг, необходимых ресурсах и возможностях снижения расходов. На этих данных будет базироваться контракт на обслуживание.
По результатам анализа потребностей бизнеса процесс планирования услуг (service planning) составляет и контролирует «портфель» стандартных услуг, необходимых большинству корпоративных заказчиков. При необходимости стандартные услуги могут быть модифицированы для решения специфических задач бизнес-подразделения. Процесс планирования услуг разрабатывает подробные спецификации ИТ-услуги, которые затем будут использоваться другими процессами управления услугами. В функции этого процесса входит также анализ рисков, связанных с реализацией услуг, определение функциональных требований, заключение стратегических альянсов для реализации услуг, прекращение предоставления услуг.
Понятие требуемого уровня предоставляемой услуги, которое может включать перечень приложений на рабочих местах, время отклика компьютерных систем, время исправления неисправностей и т.д., является важнейшей составляющей управления информационными услугами и поддерживается процессом управления уровнем услуг (service level management). В ходе этого процесса на основе заданных параметров стандартной услуги и оценок ее стоимости определяется, обсуждается с заказчиком, отслеживается и фиксируется в отчетах необходимый заказчику уровень услуг. Подробные спецификации услуг, полученные в результате выполнения процесса планирования услуг, являются отправной точкой для заключения осмысленных соглашений SLA.
Процесс управления безопасностью (security management) - одна из недавних доработок Типовой модели НР. Его появление вызвано критическим значением гарантированной защиты компьютерной инфраструктуры для нормального функционирования электронного бизнеса. Процесс управления безопасностью определяет и контролирует параметры защиты корпоративной информации и ИТ-услуг, реализует и поддерживает инфраструктуру информационной безопасности в компании. Все услуги, предоставляемые отделом автоматизации, должны в обязательном порядке удовлетворять тем стандартам защиты, которые формулирует этот процесс. Функции процесса управления безопасностью включают определение корпоративной политики защиты и доведение ее до каждого сотрудника ИТ-подразделений, анализ проблем с защитой, оценку рисков, связанных с защитой информации, анализ возникающих инцидентов и др.
Процесс обеспечения готовности ресурсов и услуг (availability management) осуществляет контроль за готовностью услуги заказчику в соответствии с его требованиями. Готовность компьютерных систем и сетей - ключевые составляющие готовности услуги в целом. Процесс обеспечения готовности услуги может привести к изменению спецификаций услуги, определенных на этапе планирования, если это необходимо для удовлетворения потребностей заказчика. Соглашения SLA, за заключение которых отвечает процесс управления уровнем услуг, должны содержать данные о том, как будет использоваться услуга, как она будет предоставляться в случае возникновения серьезных внештатных ситуаций (подключение внешней резервной системы, реализация системы реагирования на аварии и т.д.), каким образом ИТ-отдел подготовится к сбоям в предоставлении услуги (например, будет поддерживать склад запасных деталей и т.д.). Эту важную информацию предоставляет процесс обеспечения готовности.
Процесс управления ресурсами (capacity management) осуществляет контроль за тем, чтобы рабочая нагрузка задействованных компьютерных ресурсов отвечала тем требованиям, которые оговорены в соглашении об уровне услуги. Этот процесс также является поставщиком данных для процесса планирования услуг и управления уровнем услуг.
Процесс снижения расходов (cost management) позволяет определить и контролировать реальную стоимость ИТ-услуги. Этот процесс прогнозирует прибыль от реализации услуги, определяет ее бюджет, анализирует, как используется услуга и соответствует ли она заданной стоимости, выдвигает предложения по совершенствованию услуги с целью снижения расходов, вычисляет и выставляет счета заказчикам. Результаты этого процесса используются процессами планирования услуг и управления уровнем услуг для оценки стоимости услуги, а также процессами «бизнес-группы».
Разработка и внедрение услуг
Процессы этой группы предназначены для разработки новых информационных услуг и совершенствования уже существующих, а также для реализации связанных с ними компонентов инфраструктуры - процедур, инструментария, установки оборудования, развертывания программ, разработки приложений, планов по обучению персонала и т.д. Информационная услуга и ее компоненты тестируются, после чего услуга интегрируется в продуктивную среду для определения следующей группы необходимых тестов. Только после успешного завершения тестирования в полном объеме услуга может внедряться в эксплуатацию.
Процесс реализации и тестирования (build&test) направлен на разработку и одобрение функциональной версии компонента информационной инфраструктуры, функции или услуги в целом. После того как сформулированы спецификации услуги, процесс реализации и тестирования получает нужные компоненты, реализует определенные функции или полномасштабное решение. Когда реализация компонента, функции или услуги завершена, проводится тщательное тестирование. В том числе проверяется соответствие компонентов и услуги принятым стандартам защиты. Процесс реализации и тестирования находится в тесном взаимодействии с процессами управления изменениями, управления конфигурациями и выпуском версии продуктивной системы.
Выпуск версии продуктивной системы (release to production) - это создание одной или нескольких копий нового или модифицированного компонента, сервисной функции и полномасштабной услуги в соответствии с подробным планом, который разрабатывается на этапе реализации и тестирования. Это процесс ввода услуги или ее компонентов в действие: он обеспечивает доставку, установку и интеграцию в рабочую среду необходимых ресурсов, реализацию механизмов поддержки и контроля за услугой, администрирование программного обеспечения, обучение пользователей и окончательные пользовательские тесты.
Оперативная поддержка
Последняя группа процессов отвечает за нормальное функционирование услуги, осуществляя оперативное управление ИТ-средой. Оперативные процессы отвечают за функционирование услуги, выполняют мониторинг и поддержку инфраструктуры услуг, разрешают и предотвращают проблемные ситуации, отслеживают удовлетворенность заказчика предоставляемой услугой.
Управление операциями (operations management) - это, скорее, совокупность нескольких различных задач и процедур, а не единый процесс. Все они вместе поддерживают повседневные действия по предоставлению ИТ-услуги в соответствии с соглашением об уровне обслуживания. Управление операциями гарантирует нормальную работу информационной среды, что, в свою очередь, обеспечивает нормальное обслуживание заказчика. Задачи управления операциями - это мониторинг состояния ресурсов, управление очередями на печать, управление резервированием, администрирование клиентов, серверов, сетей, пользователей, IP-адресов и баз данных и т.д.
Управление инцидентами (incident management) или служба поддержки (Help Desk) - процесс быстрого восстановления готовности услуги с наименьшими потерями в случае возникновения инцидентов в инфраструктуре. Служба поддержки обрабатывает звонки пользователей, регистрирует информацию о сбое, определяет приоритеты разрешения инцидентов. Управление инцидентами предполагает повседневное взаимодействие потребителя и поставщика услуги, являясь ценным источником информации о том, насколько пользователь удовлетворен ИТ-обслуживанием.
Если управление инцидентами - это оперативное реагирование на сбои, то управление проблемами (problem management) реализует упреждающий подход, позволяя выявить корневые причины сбоев и предотвратить их до того, как они окажут необратимое воздействие на информационную среду. Исходной информацией для анализа служат инциденты, которые разрешены предыдущим процессом. Управление проблемами включает анализ тенденций возникновения проблемных ситуаций, оценку и контроль известных ошибок в инфраструктуре, информирование других процессов о потенциальных проблемах.
Реализация ITSM
Достоинство Типовой модели НР в том, что она не имеет определенных точек начала или конца; внедрение ITSM на ее основе можно начинать с любых процессов. Но есть несколько вариантов, которые наиболее типичны, поскольку помогают организациям быстро справиться со своими проблемами.
Одна из наиболее болезненных ситуаций для ИТ-отдела - плохо работающая служба поддержки пользователей. Учащаются их жалобы, проблемы повторяются из раза в раз, растет список неразрешенных проблем. Причина, как правило, кроется в том, что отсутствуют или неправильно реализованы процессы управления инцидентами и проблемами. Беда в том, что в ИТ-отделе часто смешивают эти две разные задачи и поручают их одним и тем же сотрудникам. Но если и тем, и другим занимается один и тот же человек, у него никогда не дойдут руки до глубокого анализа; все время будет уходить на разрешение текущих инцидентов. Необходимо строго разграничить два этих процесса; тогда служба поддержки пользователей заработает нормально и ИТ-отдел сможет спрогнозировать проблемные ситуации и повысить надежность информационной инфраструктуры.
Если ИТ-отдел хочет стать поставщиком услуг, ему необходимо задуматься о том, каким образом он будет определять потребности своих клиентов и добиваться нужного качества обслуживания. А бизнес-подразделения хотят иметь возможность выбора нужных услуг, приобретения пакетов услуг. Для этого они должны как минимум понимать, что им предлагают. Но для ИТ-персонала проблематичной может оказаться даже попытка сформулировать возможности автоматизации на языке, доступном неспециалисту. Отношения ИТ-отдела с бизнес-подразделениями требуют формализации. Механизмом такой формализации являются соглашения SLA. Процесс управления уровнем услуг помогает выполнить все действия для заключения таких соглашений и, в совокупности с другими процессами, выявить необходимые связи между ИТ и бизнесом и получить общее видение услуг необходимого качества.
Наконец, реализацию ITSM часто начинают с процесса управления изменениями, поскольку он действительно играет ключевую роль для стабильной работы информационной инфраструктуры в компании. Без такой стабильности невозможен переход от поддержки технологий к предоставлению ИТ-услуг. Не менее важна реализация процесса управления конфигурациями. Если такой процесс есть, менеджер, отвечающий за изменения, быстро получит информацию об элементах конфигурации, с которыми связаны изменения, и сможет эффективно проанализировать возможные риски и влияние изменений на ИТ-среду. Служба поддержки пользователей будет иметь возможность автоматически получать список информационных ресурсов (ПК, приложения, соглашения SLA...), которые задействует обратившийся к ней пользователь. Эти примеры можно продолжать.
ITSM - новая для ИТ-отделов концепция. Но ее необходимость диктуется жизнью. Слишком велика сегодня роль информационных технологий для бизнеса, особенно для его «е»-компонента. То, что в Hewlett-Packard активно занялась этой проблемой, конечно, не случайно: технологическая основа для автоматизации работы ИТ-отдела - это платформа управления компьютерными системами и сетями HP OpenView ( , «Открытые системы», 2000, №7-8). Входящий в нее компонент IT Service Manager использует концепцию процессов и является обязательным компонентом проектов НР при развертывании ITSM-решений IT Service Manager интегрирован с другими компонентами OpenView, которые обеспечивают управление уровнем услуг, сбоями, проблемами, изменениями, позволяют взглянуть на информационные ресурсы с точки зрения бизнес-процессов и т.д. Внедрение ITSM-решений на основе Типовой модели и платформы OpenView в HP начали с себя, реорганизовав работу собственного ИТ-подразделения в соответствии с концепцией управления качеством информационных услуг.
