В определенный момент развития компании руководство ИТ-подразделения может столкнуться с ситуацией, когда решение инцидентов занимает слишком много времени, пользователи оказываются недовольны предоставляемыми услугами, а внутренняя организация работы представляет собой полный хаос. Одним из вариантов решения этих проблем является внедрение ITSM (Information Technology Service Management). В рамках этого поста, которым мы решили открыть свой блог на Хабре, мы поговорим о том, что такое ITSM, и рассмотрим некоторые возможности платформы ServiceNow.

Что такое ITSM?

ITSM - это сервисный подход к управлению ИТ, когда деятельность ИТ-подразделения рассматривается как перечень услуг, которые оно предоставляет другим отделам в соответствии с SLA. То есть, задача ITSM сделать так, чтобы ИТ-отдел стал полноправным участником бизнеса и выступал в роли сервис-провайдера для подразделений компании. В этом случае он перестает быть вспомогательным элементом, ответственным только за работу отдельных серверов, сетей и приложений.

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

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

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

Реализация ITSM - ServiceNow

Сегодня, согласно отчету Gartner, одним из самых популярных ITSM-сервисов на рынке является платформа ServiceNow. «ИТ Гильдия» - официальный партнер компании ServiceNow Ltd., мирового лидера среди поставщиков ПО для управления службой поддержки, достаточно давно работает с платформой ServiceNow, обеспечивая интеграцию, администрирование и техническое сопровождение. Поэтому мы на собственном опыте убедились, что ServiceNow - это гибкая платформа, предоставляющая большие возможности конфигурации под процессы клиента.

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

Это позволяет применить модель ITSM для финансовой службы, HR, службы кадров, маркетинга, а также с помощью единой платформы управлять аналитикой, разработкой, ресурсами, проектами и прочими направлениями бизнеса. А также для типовых ITSM-практик, например, обработки запросов пользователей. Далее, мы рассмотрим несколько решений, которые позволяет применить SaaS-платформа ServiceNow.

Управление ИТ и управление рисками (GRC)

GRC (Governance, Risc, Compliance) - это совокупность процессов и продуктов, участвующих в определении и достижении бизнес-целей и одновременно снижающих риски. GRC в ServiceNow реализована тремя приложениями, полностью интегрированными в основную платформу.

Первое приложение называется ServiceNow Risk Management и обеспечивает централизованный процесс выявления, оценки, реагирования и постоянного мониторинга корпоративных и ИТ-рисков, которые могут негативно повлиять на бизнес. Приложение имеет графический интерфейс для создания профилей и зависимостей с целью сопоставления и моделирования рисков.

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

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

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

Третьей приложение GRC-комплекса - это Audit Management. Оно дает возможность планировать аудиторские задания, контролировать выполнение и предоставлять отчеты ответственным лицам. Отчетность о взаимодействии гарантирует, что стратегия управления рисками организации и соблюдением законодательства эффективна. Процесс аудита включает в себя создание, планирование, определение области охвата и проведение аудиторских заданий, а также отчетность о результатах.

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

Управление разработкой ПО (Agile Development)

Платформа ServiceNow также включает в себя приложения для гибкой разработки. Решение ServiceNow Agile Development (SDLC) позволяет управлять методами гибкой разработки Scrum при работе над программным обеспечением и его сопровождением на протяжении всего жизненного цикла. Приложение Agile Development представляет собой последовательный процесс для среды разработки программного обеспечения.

Платформа дает возможность проводить ежедневные совещания (Daily Scrum) с членами команды с целью обсуждения текущих проектов, запланированных работ и затруднений. Здесь также имеется возможность вести бэклог продукта, представляющий собой список пользовательских историй, упорядоченных по степени важности. Product Backlog можно регулярно просматривать и дополнять по мере появления новых требований и пересмотра приоритетов.

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

Управление ИТ-инфраструктурой (IT Operations Management)

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

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

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

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

И это лишь несколько функций, которые реализует платформа ServiceNow. В списке предоставляемых услуг можно найти такие пункты, как

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

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

Развитие бизнес-процессов в современном мире

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

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

В 20-х годах XX века процессы начали описывать не только словами и последовательностью, но простейшими блок-схемами с графическим оформлением взаимосвязей на подобии: «если сделать так – будет это, если сделать иначе, будет то». Потом пришло время связанных алгоритмов, вместе с которыми бизнес-процессы, как элемент управления эффективностью и предприятием в целом, все более формализуется и закрепляется в качестве MUST HAVE во всех отраслях предпринимательской деятельности.

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

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

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

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

Бизнес-процесс как ключ к успеху

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

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

Именно в совокупности результатов различных процессов компании и заключается цель основной деятельности.

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

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

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

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

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

Автоматизация бизнес процессов как путь в будущее

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

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

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

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

Компании сталкиваются с разными сложностями при автоматизации бизнес процессов в зависимости от своих внутренних особенностей.

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

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

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

1. Ошибки при переносе процесса в автоматизированную систему – самая частая проблема, вызванная желанием сэкономить. Неопытные менеджеры, чаще всего сами держатели процесса, пытаются перенести свою работу в информационное поле и автоматизировать. В результате – потеряны детали, нарушена или вообще не соблюдается логика, нет последовательности автоматических действий, а весь автоматизированный процесс можно назвать разве только «костылем». Это логичный результат, потому что профессионалы продаж не могут быть профессионалами в области построения автоматизированных бизнес процессов. Такая работа требует особой квалификации и опыта, а результат может быть достигнут только совместными усилиями узких специалистов и владельца процесса. Если речь идет о процессе распространяющимся за рамки одного подразделения или компания решила автоматизировать сложный процесс (закупочный, производственный и т.п.), то только квалифицированная команда способна детально исследовать процесс «как есть» и создать работоспособную автоматизированную схему.
2. Саботаж автоматизации – это проблема, которая делит пальму первенства с ошибками при переносе процесса в автоматизированную систему. Команда, понимая, что автоматизированный процесс высвобождает у них временной ресурс, начинает мешать внедрению автоматизации, руководствуясь инстинктом самосохранения или элементарным нежеланием что-то менять в работе и учиться новому. Эту проблему достаточно сложно нивелировать на сто процентов, хотя при грамотном менеджменте и наличии реальных планов на ресурс в лице персонала, можно донести до команды, почему менеджмент принял решение об автоматизации, и какую роль в дальнейшем будет играть тот или иной специалист. Конечно, это не сработает, если ключевая цель автоматизации – сокращение издержек на персонал (а для многих компаний персонал по-прежнему остается самым дорогостоящим звеном).
3. Техническая неподготовленность персонала – проблема, которая проявляется, как правило, либо в самом начале автоматизации, либо, наоборот, когда проект закончился и уже запущен. Вопрос торможения автоматизации в связи с техническими затруднениями, по сути, меньшее из зол, с которым можно столкнуться в этой сложной работе, поскольку всегда есть возможность произвести обучение персонала и создать в компании внутреннюю систему наставничества во избежание таких проблем в будущем.
4. Не рассчитали свои силы – проблема инвестиционного характера. Планы на автоматизацию формулировались колоссальные, ресурсы компании были посчитаны неверно, и поэтому в какой-то момент стало очевидно, что на реализацию проекта не хватает ресурсов. Что делать? Оптимизировать сам процесс внедрения (время, скорость), искать ресурсы (заемные, отсрочки), менять условия (добиваться скидок, менять подрядчиков, сокращать объемы команд) и искать возможности для завершения процесса автоматизации любыми доступными способами, если он в итоге сулит компании прибыль.

Если указанные выше ошибки бизнесу удалось преодолеть, поскольку проблемные ситуации были проработаны заранее, перед ним встанет вопрос, как правильно отрегулировать автоматизированный бизнес процесс. Рассмотрим свойства таких бизнес-процессов поподробнее:

• Автоматизированный бизнес процесс должен обладать целью и задачами, которые компания решает в рамках этого бизнес процесса. Это значит, что любой пользователь процесса и менеджер компании, взглянув на бизнес процесс, может понять, какова конечная цель бизнес процесса, какие задачи необходимо выполнить, а также кто возьмет на себя ответственность за их выполнение на пути к этой цели. Например, если автоматизированный бизнес процесс – кросс-сейл товарных остатков прошлого года, то глобальная цель такого проекта заключается в том, чтобы распродать залежавшийся товар. Задачи на пути к достижению этой цели: формирование товарного ассортимента, написание скрипта на сайт, прикрепляющего товары по особому алгоритму в рекомендации покупателям, е-мейл рассылка по установленным правилам, установление скидок на товар прошлой коллекции и прочие действия, за каждым из которых закрепляется ответственный специалист или подразделение.
• Четкий автоматизированный процесс должен быть отрегулирован во времени. Это фактически главный принцип процессного управления: все действия и организация работы должна укладываться в какое-то регламентное время. Соответственно, говоря о первом примере с распродажей остатков, у такого проекта должен быть определен диапазон активности и скорость продуктивности. Диапазоном будет ограничено время начала работы и подведения результатов по процессу в целом, а скорость продуктивности (также измеряемая временем) даст возможность анализировать вклад каждого звена процесса в общий результат, контролируя при этом нарушение сроков исполнения работ, не обоснованное объективными причинами.
• Автоматизированный бизнес процесс должен иметь разделение на этапы и точки контроля. Это помогает контролировать ход выполнения процесса в зависимости от его стадии или фазы, распределять ответственность между участниками процесса и дополнительно оперативно анализировать процесс на этапе неполного завершения. Важно заметить, что внутри этапов команде предоставлена максимальная свобода действий и последовательности их активностей, но на точках контроля требуется жесткая отчетность по нормативному результату этапа и беспрекословное соблюдение назначенных сроков.
• Система нормативов автоматизированного бизнес процесса должна содержать достаточно сведений для возможности контролировать ход процесса. Процесс обязательно регламентируется набором документов и отчетностью. Совокупность этих элементов управления процессом позволяет команде искать выходы из затруднительных ситуаций в рамках установленного поля, а не просто следуя инструкции.
• Автоматизированный бизнес процесс можно рассмотреть не только с точки зрения указанных ранее аспектов, но и в разрезе используемых для его реализации ресурсов: рабочих часов, финансов, оборудования, технологий и прочего. Все эти вопросы должны быть изначально продуманы и рассмотрены на этапе внедрения бизнес процесса с учетом неких прогностических изменений ситуации, чтобы гарантировать завершение бизнес-процесса запланированным результатом.
• Ответственные за исполнение и результативность бизнес процесса люди. Насколько бы ни была совершенной система автоматизации бизнес-процессов, ей нужен живой контролер, способный смотреть на ситуацию глобально и критически. Поэтому любой автоматизированный бизнес процесс должен быть обеспечен ответственными за его исполнение сотрудниками, задача которых заключается не только в предметной функции, но и в контроле ключевых точек процесса.
• Информирование участников – важнейший элемент взаимосвязанной системы бизнес процессов, который является также и инструментом контроля. Наибольшую продуктивность показывают системы автоматического информирования обо всех происходящих в бизнес процессе действиях, построенные по принципу точек, на которых система сама генерирует уведомления и информирует особый список участников. Конечно, ручное информирование тоже работает, но требует дисциплины и очень часто дает определенные сбои.

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

Карта бизнес процессов

Компания: IT Premium

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

С кем проводилась работа: Максим Прокопов, CEO и со-учредитель.

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

Изначальная информация

По итогам первого обсуждения мы с Максимом, подготовили наброски карты, которая приняла следующий вид:

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

Карта основных бизнес процессов компании IT Premium

Карта основных бизнес процессов IT Premium

Как видите, изменения колоссальны. Но что самое важное – мне удалось донести свое видение и методику подготовки карты процессов, до директора компании. Вот что говорит на эту тему сам Максим:

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

В процессе работы с Романом неясные места становились все более ясными, и, в результате “домашней работы” у меня получилось построить карту процессов самостоятельно от начала и до конца!

Считаю это большой заслугой Романа, как человека, который четко и ясно может донести мысль и вложить ее в мозг заказчику.

Спасибо за проведенный эксперимент.

Со своей стороны хочу сказать спасибо Максиму! Было здорово поработать вместе. Мы получили хорошую, рабочую карту процессов.

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

Краткое описание основных процессов

Основные процессы:

Прием заявок – процесс отвечает за прием и обработку всех клиентских заявок, вне зависимости от того, в первый раз обращается клиент или нет. Сначала заявка регистрируется в системе и затем проходит обработку, в результате которой, определяются все необходимые, для выполнения, условия и назначается ответственный. Результатом процесса является, обработанная и назначенная исполнителю, заявка. Если заявка относится к одному из следующих типов:

• Заявка на разовое обслуживание
• Первичное обращение клиента
• Заявка на обслуживание, выходящее за рамки ранее заключенного контракта

То заявка переходит в процесс «Согласование объема услуг и стоимости»

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

Мониторинг ИТ системы заказчика – процесс заключается в регулярном осмотре ИТ системы клиента. Процесс запускается если у заказчика есть такое требование. Может проводится мониторинг как всей системы так и отдельных ее частей, а так же как удаленно так и с помощью выезда специалиста. Условия определяются в процессе «Согласование объема и стоимости». Тем не менее, даже периодическое звонки менеджеров с простым вопросом «Все ли у вас хорошо работает?», являются мониторингом. Такое обслуживание может проводиться не только по требованию клиента но на усмотрение ответственных менеджеров.

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

Вспомогательные процессы:

Коммуникации с клиентом – все контакты с клиентом и все что с этим связано. Данный процесс отвечает на следующие вопросы:

• Кто связывается с клиентом?
• С кем связывается клиент?
• Какие каналы коммуникаций используются?
• Какие сообщения доносятся до клиентов?
• В какой форме проходят сообщения?
• И т.д.

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

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

Персонал – все что касается набора, обучения, мотивации и текущей работы с персоналом компании.

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

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

Коммуникации с поставщиками – данный процесс дублирует цели и задачи процесса «Коммуникации с клиентом», но в отношении поставщиков.

Процессы управления:

Контроль ключевых показателей – процесс определяет кто, с какой периодичностью и какие контролирует показатели. Естественно данный процесс отвечает за разработку и внедрение действий, связанных с приведением показателей в норму.

Управление ресурсами – процесс отвечает за распределение и координацию всех ресурсов компании по процессам. Так же данный процесс отвечает за обеспечение ресурсами внутренних процессов и нужд компании.

Управление бизнес процессами – основная цель данного процесса – разработка, внедрение и оптимизация всех бизнес процессов компании. Постоянное улучшение деятельности компании – одна из задач данного процесса.

Управление продуктами – анализ, разработка, реализация и внедрение новых продуктов компании.

Стратегическое планирование и развитие – процесс, результатом которого является стратегия компании. Ее разработка, обеспечение, контроль и т.д. Совместно с процессом «Управление бизнес процессами», отвечает за эффективность и успех компании.

Управление финансами – управление финансовыми потоками.

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

Документ разработан для руководителей отделов программирования, директоров компаний, занимающихся разработкой собственного программного обеспечения, директоров по качеству, директоров по развитию, аналитиков бизнес-процессов.

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

Бизнес-процессы организации

Любая организация, выполняя свои функции, представляет себе, какие из них являются основными, какие обеспечивающими или дополнительными. Начиная с 2000 года, большинство методических рекомендаций определяет так называемый процессный подход к деятельности любых организаций. Для того, чтобы понять, что обозначает этот термин, необходимо определить понятия Процесс, Функция.

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

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

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

Очевидно, что даже если в организации не определены процессы, они существуют в том или ином виде.

Задачей любого менеджера, в соответствии с современными представлениями об организации, является определение всех процессов (бизнес-процессов) организации в соответствии с определением процесса, а именно описать:

1. Цели и задачи бизнес-процесса (прагматические характеристики);

2. Владельца (хозяина) бизнес-процесса;

3. Последовательность выполняемых функций;

4. Поток входной/выходной информации (материалов);

5. Используемые ресурсы;

6. Регламент бизнес-процесса (руководящие, описательные документы, стандарты).

При анализе бизнес-процессов менеджер (аналитик) должен определить основные производственные бизнес-процессы и вспомогательные. Например, основными производственными процессами являются: сборка автомобилей для сборочного завода, процесс разработки ПО для программистской организации, прокачка газа для газотранспортного предприятия. Вспомогательные (обеспечивающие) процессы, как правило, очень похожи во всех организациях и описаны в стандарте ИСО 9001:2008. Это такие процессы как: управление (включающее управление персоналом), закупки, продажи, складское хранение, контроль (обеспечение) качества продукции и др.

Общность процессов

Все бизнес-процессы организаций известны и определены стандартом ISO 9001:2008.

Список бизнес-процессов включает в себя:

1. Производство;

2. Управление;

3. Документирование;

4. Управление закупками;

6. Корректирующие и предупреждающие действия;

7. Управление качеством;

8. Управление жалобами клиентов.

Уникальность программистских организаций

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

Известные программистские организации (Микрософт, Моторола, IBM, ORACLE) уделяют вопросам качества программного кода огромное значение. Как правило, на проверку правильности программ уходит в 5-10 раз больше ресурсов, чем на их производство. В этом как раз и заключается уникальность таких организаций. Трудно себе представить, чтобы измерение детали после токарной обработки занимало в 10 раз больше времени, чем сама обточка этой детали.

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

Уникальность процесса производства

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

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

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

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

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

С чего начать разработку собственной фирменной методики производства ПО?

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

В области качества программного продукта цели ставятся достаточно стандартные. Это:

1. Уменьшение сроков и стоимости разработки;

2. Корректность кода;

3. Исключение ошибок;

4. Повышение надежности;

5. Повышение эффективности автоматизируемых функций;

Все эти цели (или подцели) полностью соответствуют целям более высокого уровня:

1. Уменьшение издержек производства и технической поддержки;

2. Увеличение прибыли;

3. Увеличение производительности труда;

4. Захват большей доли рынка;

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

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

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

1. Определение требований клиента (клиентом могут быть и внутренние структуры организации);

2. Системное проектирование (разработка требований, спецификаций, анализ и синтез будущей системы с точки зрения элементного состава, межэлементных и внешних связей, границ системы, функциональных требований и т.п.);

3. Техническое проектирование (детализация требований, спецификаций, проектирование и разработка отдельных элементов и т.д.);

4. Разработка системы;

5. Верификация (тестирование, опытная эксплуатация и т.п.);

6. Выпуск системы (релиз, версия);

7. Сопровождение системы.

Параллельно с процессом производства ПО выполняются следующие процессы:

Общие для любого производства:

1. Управление;
2. Управление качеством;
3. Документирование;
4. Управление закупками/продажами;
5. Управление маркетингом;

Специфические для производства ПО:

1. Управление конфигурацией;
2. Управление требованиями;
3. Тестирование (модульное, интегральное, нагрузочное и т.п.).

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

Управление конфигурацией

Основы процесса Управление конфигурацией определены локализованным в России стандартом: ГОСТ Р ИСО 10007-2007. К сожалению, локализованный стандарт в силу языкового (и процессного) барьера нетривиален в своем применении, поэтому мы попытаемся в упрощенной форме изложить его требования. Благодаря такому изложению любая компания может построить процесс управления конфигурацией в течение 2-3 месяцев.

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

Базовая конфигурация - целостная совокупность данных о продукте, прошедшая процедуру утверждения и принятая в качестве базового описания конфигурации (эталона). Базовые конфигурации периодически обновляются, образуя новую базовую линию в последующий момент времени путем учета истории авторизуемых изменений. Например, часто программистские компании выпускают версии своих продуктов под номерами 3.02, 3.03, … 3.10… 4.00. При этом подразумевается, что целая часть числа обозначает базовую конфигурацию программного продукта, десятые и сотые части – обозначают промежуточные версии программного продукта, отличающиеся от базовой конфигурации исправленным кодом (вследствие устранения ошибок), добавлением небольших модификаций для конкретного предприятия-клиента или для группы предприятий.

Управление конфигурацией – действия, направленные на формирование базовой конфигурации и контроль над изменениями конфигурации (версии).

Как и все процессы, процесс Управления конфигурацией состоит из следующих подпроцессов:

1. Планирование;

2. Идентификация конфигурации;

3. Управление изменениями;

4. Аудит конфигурации.

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

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

Управление требованиями

Целями процесса Управления требованиями является получение окончательного продукта, соответствующего актуальным требованиям заказчика на момент выпуска этого продукта. Если говорить проще, то процесс Управления требованиями предназначен для отслеживания постоянных изменений требований заказчика, учета новых требований в производимом продукте и выпуске соответствующего продукта.

Большинство специалистов любого производства скажут, что такое невозможно, ведь требования к продукту могут меняться на противоположные уже по ходу производства, что исключит выполнение таких критериев качества, как стоимость и сроки разработки продукта. Но в том и заключается окончательный результат процесса Управления требованиями – ведь если требования изменились на противоположные относительно начала работ, следовательно, заказчику уже не нужен продукт с начальными характеристиками и требованиями. Какой смысл производить то, что уже не нужно?

В процесс Управления требованиями входят следующие подпроцессы:

1. Планирование;

2. Определение начальных требований;

3. Выявление пропущенных требований (например, тех, которые заказчик предполагал в силу своего собственного контекста);

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

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

6. Проверка выполнения требований в продукте (верификация, валидация).

Процесс Управления требованиями подробно описан в стандарте SW CMM, Уровень 2.

Тестирование

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

Процесс тестирование также состоит из подпроцессов:

1. Планирование;

2. Разработка отдельных тестов для каждого требования, подсистемы, модуля и т.п.;

3. Управление изменениями тестовых процедур и тестов по мере изменения требований;

4. Тестирование отдельных элементов (требований) системы;

5. Интегральное тестирование, нагрузочное тестирование (если предусмотрено техническим заданием).

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

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

1. Разработчика (программист проверяет собственный код);

2. Независимого разработчика (проверку исполнения алгоритмов проводит программист, не занимающийся данной реализацией);

3. QA (Quality Assurance) – проверку кода осуществляет специальная тестовая группа в соответствии со стандартными правилами;

4. Пользовательский (до выпуска продукции необходимо, чтобы тестирование провел специалист предметной области, например, бухгалтер).

По оценкам специалистов Motorola, ORACLe трудоемкость (затраты) тестирования должны составлять не менее 100% от трудоемкости (затрат) на собственно кодирование.

Существует нормальное распределение отношения затрат к количество выявленных ошибок. Из этого распределения следует, что после некоторой суммы затрат на тестирование, дальнейшие затраты на выявление каждой ошибки растут экспоненциально. Обычно эта зависимость возникает после затрат, превышающих в 5-10 раз затраты на производство кода. То есть, оптимальное соотношение тестирование/производство должно составлять от 1 до 5.

Выводы

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

Очевидно, что это приводит уже к потере качества продукта, потере клиентской базы и, как следствие, к потере прибылей компании.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Введение

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

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

Объект исследования диссертации: бизнес-процессы в ИT.

Предмет исследования диссертации: организация моделирования бизнес-процессов и управления в ИT предприятии.

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

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

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

Задачи, поставленные для достижения цели:

1) Проведение анализа литературных источников по поставленной проблеме:

· Определение роли концепции управления ИT-услугами в понимании бизнес стратегии;

· Определение этапа развития сервисного подхода к управлению бизнес-процессами в ИТ;

· Проведение обзора и анализа существующих методик, методологий, лучших практик, рекомендаций, которые используются для управления ИT-процессами (ITIL, COBIT, ISO 20000);

2) Проведение исследования основных бизнес-процессов в ИT:

· Описание бизнес-процессов, их назначения, целей, задач и функций.

· Определение окружения и взаимодействия с другими процессами.

· Определение метрик процессов.

· Определение документирования процессов.

· Описать процессы, происходящие внутри каждого бизнес процесса.

· Разработать схемы моделирования бизнес процессов в ИT.

4) Построить общую инфраструктуру ИТ-предприятия.

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

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

Магистерская диссертация представлена на ____ стр. текста и состоит из введения, четырех глав, заключения и списка литературы.

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

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

В третьей главе проведено моделирование бизнес-процессов, описаны операции, протекающие на всем цикле работ, разработан каталог рисков, безопасности и метрик.

В четвертой главе описана общая инфраструктура всех процессов.

1. Обзор решений моделирования бизнес-процессов управления ИT сервисами

1.1 Роль концепции управления ИT-услугами в понимании бизнес стратегии

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

В 2000-х годах в результате мощного прогресса информационных технологий, в том числе и благодаря освоению ресурсов интернет пространства, всеобщая доступность ИT-услуг привела к повсеместной интеграции во взаимодействии человека с компьютером. Современные средства вычислительной техники являются не только неотъемлемой частью повседневной жизни людей (доступность технических средств, появление различных торговых площадок в сети интернет, онлайн-сервисов, интернет-магазинов, интернет-банкингов, интернета-вещей, развитие интеллектуальных систем и технологий Big Data), но и главным двигателем бизнеса.

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

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

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

1.2 Сравнительный анализ существующих подходов к управлению IT-услугами

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

Выполнение заданий, связанных с ИТ обеспечением предприятия (внедрение, сопровождение),

Обеспечение стабильного функционирования ИТ комплекса.

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

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

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

Сервисный подход применяется для повышения качества и эффективности ИТ-услуг и сервисов. Ключевыми преимуществами от использования сервисного подхода в ИТ являются следующие показатели:

· повышение качества услуг, предоставляемых конечным пользователям;

· обеспечение непрерывности бизнес-процессов и услуг;

· сокращение затрат на содержание ИТ-инфраструктуры.

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

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

Таким образом, современные ИT-организации стараются обеспечить предоставление услуг и сервисов своим заказчикам с достаточно высоким процентом уверенности в результате и при удовлетворительном размере затрат.

1.3 Анализ существующих методик, стандартов и подходов к управлению ИT-процессов

Существующие подходы по управлению ИТ-услугами и сервисами можно разделить на две группы: «лучшие практики» и стандарты (международные, национальные, отраслевые и специализированные стандарты в области ИТ).

В основу «лучших практик» («best practice») и методологий различных подходов к управлению ИТ-услугами, разработанных крупными компаниями-вендорами входят следующие группы: методологии управления ИТ-услугами (ITIL, MOF, HP References model), подходы к руководству ИТ (IT Governance, CobiT), а также, частично, методологии управления проектами (IPMA, PMI, PRINCE2) в части управления проектами в области ИТ.

К стандартам относится первый в мире международный стандарт по управлению услугами ISO 20000, стандарты в области управления информационной безопасностью ISO 27001, стандарты в области разработки программного обеспечения ISO 12207, ISO 15288, ISO15504 и другие.

1.3.1 Библиотека ITIL

ITIL (IT Infrastructure Library) - библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Создание проекта началось в 80-е годы Центральным агентством по вычислительной технике и телекоммуникациям (CCTA - Central Computer and Telecommunications Agency). Целью проекта было создание подхода, который бы помог результативно и эффективно использовать IT-ресурсы в министерствах и других государственных учреждениях по заказу британского правительства. Результатом работ стала Библиотека опыта организации IT (IT Infrastructure Library -- ITIL), которая собрала лучшие подходы, имеющиеся на тот момент в индустрии IT-услуг.

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

Рассмотрим основные принципы, на которых основана модель ITIL:

Процессный подход к построению деятельности IT-департамента;

Услуга как конечный продукт IT-подразделения;

Высокое качество предоставляемых услуг;

Вектор внимания на Потребителя;

Ключевые отношения Поставщик-Потребитель;

Взаимовыгодные отношения с Поставщиками.

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

Основное внимание уделяется 12-ти практическим управленческим методам, которые применяются в различных областях в зависимости от потребностей организации (рис. 1.1).

Рисунок 1.1 - Библиотека ITIL

Библиотека ITIL состоит из подробных сведений, которые отвечают на один из вопросов о том, каким образом возможно предоставление и поддержание ИТ-услуг и сервисов (Service Delivery, Service Support, Application Management). В практике описываются процессы создания, развертывания и поддержания ИТ-инфраструктуры (Infrastructure Management) на качественном уровне, способном соответствовать всем ожиданиям клиента.

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

Применение ITIL организацией позволяет решать следующие задачи:

· Повышать эффективность выполнения протекающих процессов, использующих современные информационные технологии, в том числе:

ь увеличение показателей продуктивности работы за счет повышения качества, уровня доступности и стабильности критичных ИТ-сервисов, гарантированного обеспечения сроков выполнения обращений и уверенность в их реализации;

ь снижение затрат, вызванных простоем компонентов ИТ-инфраструктуры, за счет сокращения времени простоя ИТ-приложений и ИТ-систем, гарантированного обеспечения сроков устранения неисправностей ИТ-инфраструктуры.

· Обеспечивать повышение качества предоставляемых услуг ИТ-сервисов путем снижения операционных затрат на обеспечение сопровождения ИТ-инфраструктуры за счет:

ь организации сервисно-процессного подхода к организации ИТ-деятельности;

ь оптимизации используемых ИТ-ресурсов (включая человеческие), эффективного распределения ролей, зон ответственности, обязанностей и полномочий сотрудников ИТ-инфраструктуры корпоративной информационной системы;

ь стандартизации, регламентации и автоматизации ИТ-деятельности, включая полную автоматизацию процессов ведения и использования базы знаний.

· Обеспечивать увеличение управляемости протекающими процессами и их развития (в том числе, повышение управляемости и прозрачности), обеспечение принятия своевременных, взвешенных и обоснованных управленческих решений за счет:

ь определения и параметризации объективных показателей оценки качества ИТ-сервисов, качества работы подразделений и сотрудников ИТ, обеспечения критериальной оценки работы ИТ-сервисов, отдельных сотрудников, подразделений и службы ИТ в целом;

ь создания системы автоматизированной отчетности, формируемой по фактическим значениям показателей качества ИТ-сервисов и работы службы ИТ;

ь создания системы непрерывного совершенствования и развития ИТ-сервисов и процессов управления ИТ.

Вывод: Библиотека ITIL представляет собой обобщенный набор «лучших практик» в области управления ИТ. Авторы ITIL создали универсальный подход, независящий от конкретных технологий и специфики организаций. Подход не является научной методологией или требованиями каких-либо стандартов. Поэтому, описания ITIL имеют рекомендательный, но не предписывающий характер.

1.3.2 MOF

Ведущи е мировые компании-вендоры, занимающиеся производством программного и аппаратного обеспечения на практике разрабатывают на основе ITIL структурированные подходы (frameworks), отображающие точку зрения своей компании на управление ИТ-услугами. Одной из самых интересных «надстроек над ITIL» является Microsoft Operations Framework (MOF).

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

Модель процессов MOF поддерживает успешное оказание ИТ-услуг при помощи следующих важнейших принципов:

Структурированная и распределённая ИТ архитектура;

Быстрый жизненный цикл, итеративное улучшение;

Управление, основанное на оценке;

Встроенное управление рисками.

Модель процессов MOF делится на 4 взаимосвязанных квадранта операционной активности: изменение, эксплуатация, поддержка и оптимизация. Каждый из квадрантов применяется на определенном этапе жизненного цикла ИТ инфраструктуры. Задача каждого из квадрантов решается путем исполнения соответствующих функций управления услугами (рис. 1.2).

Рисунок 1.2 - Модель процессов MOF

MOF является моделью, которая дает понимание какие мероприятия возможно организовать, чтобы обеспечить полный цикл управления ИТ-услугами и сервисами.

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

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

Вывод: Значительным и достаточно критичным недостатком MOF есть тот факт, что данная «надстройкой над ITIL» является непосредственным подходом Microsoft к управлению ИТ-услугами и использованием продуктов именно в рамках данной конкретной организации. Применение MOF нельзя считать универсальным подходом, возможным для использования в других компаниях или организациях, т.к. он представляет из себя крайне узконаправленный и подточенный под конкретную организацию подход не гарантирующий успех.

1.3.3 Стандарт CobiT

Стандарт Control Objectives for Information and related Technology (CobiT) представляет собой набор универсальных задач ИТ управления. Его ценность заключается в том, что он предлагает модель, обеспечивающую взаимосвязь между бизнес-целями и ИТ-процессами.

В основе стандарта CobiT лежит парадигма, гласящая о том, что для предоставления информации, которая необходима организации для достижения ее целей, ресурсы ИТ должны регламентироваться набором естественно сгруппированных процессов. ИТ-ресурсы в CobiT описываются через четыре составляющие: приложения (Applications), данные (Information), инфраструктура (Infrastructure), люди (People).

CobiT содержит верхнеуровневое описание 34-х ИТ-процессов различных аспектов корпоративного ИТ управления. Все процессы сгруппированы в четыре домена (рис. 1.3):

· Планирование и организация (Plan and organize);

· Приобретение и внедрение (Acquire and implement);

· Предоставление и поддержка (Deliver and support):

ь Определение и управление уровнями сервиса,

ь Управление сервисами подрядчиков,

ь Управление производительностью и мощностью,

ь Обеспечение непрерывности сервисов,

ь Обеспечение безопасности систем,

ь Определение и распределение ИТ затрат,

ь Обучение пользователей,

ь Управление службой поддержки и инцидентами,

ь Управление конфигурацией,

ь Управление проблемами,

ь Управление данными,

ь Управление физическим оборудованием,

ь Управление эксплуатацией,

· Мониторинг и оценка (Monitor and evaluate).

Рисунок 1.3 - Стандарт CobiT

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

Достоинствами CobiT является четкая структура механизмов контроля процессов и возможности проведения аудита ИТ-процессов на соответствие требованиям.

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

· определить четкие требования к ИТ-службе;

· произвести комплексный взгляд на протекающие внутри организации бизнес-процессы;

· оценить риски и удостовериться в оптимизации затрат на ИТ-сервис;

· обеспечить заинтересованность, как со стороны руководства, так и со стороны рядовых сотрудников к внедрению ИТ-службы, обеспечить мотивацию к процессу внедрения и сопровождения, а также сформировать критерии ценности;

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

Единственное, что не описано в CobiT - это вопросы внедрения процессов, механизмы осуществления деятельности (включая управление) процессов, меры по совершенствованию ИТ процессов и услуг.

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

1.3.4 Стандарт ISO 20000

Первый в мире стандарт в области управления услугами официально разрабо танный Британским институтом Стандартизации (British Standard Institute) - BS 15000. Стандарт ISO/IEC 20000 «определяет требования к поставщику услуг по предоставлению потребителю управляемых услуг приемлемого качества» и «должен способствовать принятию в повседневной практике процессного комплексного подхода к эффективному предоставлению управляемых услуг».

ISO/IEC 20000 состоит из двух частей:

· Information Technology - Specification for Service management (ISO/IEC 20000-1: 2005). Набор формальных требований для организации предоставления ИТ-услуг с требуемым качеством;

· Information Technology - Code of Practice for Service management (ISO/IEC 20000-2:2005). Практическое руководство по управлению ИТ-услугами. В нем в форме рекомендаций подробно раскрываются подходы к достижению формальных требований, изложенных в первой части стандарта.

Рисунок 1.4 - Стандарт ISO/IEC 20000

Стандарт ISO/IEC 20000 вобрал в себя принципы процессного подхода и содержит ряд требований к процессам управления ИТ-услугами. В стандарте описаны процессы управления услугами (рис. 1.4), но не отображены взаимосвязи между процессами.

Согласно стандарту, необходимо обеспечить «систему управления, включающую политики и организацию управления, позволяющую реализовывать внедрение всех услуг ИТ и эффективное управление ими». Планирование и реализация управления услугами реализуется через цикл Деминга «Plan-Do-Check-Act» (PDCA). При этом описание цикла и действий, которые должны быть осуществлены на каждом этапе, практически полностью совпадают с описанием цикла PDCA, приведенного в стандарте ISO/IEC 9000 с учетом специфики ИТ-услуг:

Ш планирование (plan) - установка целей управления услугами и определения процессов управления услугами, необходимых для получения результатов, соответствующих требованиям потребителей и политикам поставщика услуг;

Ш реализация (do) - внедрение процессов управления услугами;

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

Ш действие (act) - выполнение действий по постоянному улучшению показателей процессов.

Вывод: Стандарт ISO/IEC 20000 можно считать одним из ключевых теоретических руководств по управлению ИТ-услугами, т.к. описанный подход к управлению услугами полностью соответствует запросам бизнеса по отношению к пониманию ИТ-инфраструктуры организации. Благодаря данному стандарту дается крайне исчерпывающее описание процессов, протекающих внутри оганизации.

1.3.5 Управление ИТ-проектами на основе PMBoK

Project Management Body of Knowledge (PMBoK) - свод знаний по управлению проектами и является американским национальным стандартом. В стандарте описывается непосредственно процесс управления проектами в терминах интеграции между процессами и взаимодействий между ними, а также цели, которым они служат.

По PMBoK управление проектами - это приложение знаний, навыков, инструментов и методов к работам по управлению процесса для удовлетворения требований, предъявляемых к проекту. Управление проектами выполняется с применением интеграции логически сгруппированных процессов управления проектами в количестве 42, распределенных в 5 групп. Эти 5 групп процессов следующие:

· инициация;

· планирование;

· исполнение;

· мониторинг и управление;

· завершение.

Вывод: Знания, которые накоплены в PMBoK по управлению проектами являются одними из наиболее часто используемых и при их правильном применении внедрение проектов в рамках ИТ-инфраструктуры будут приносить прибыль и обеспечивать эффективные показатели качества.

1.3.6 Управление ИТ-проектами на основе PRINCE2

PRINCE2 является методом для упра вления проектами, разработанным для британского правительства и является обязательным для применения во всех государственных структурах Великобритании. Благодаря открытости, доступности и эффективности этого метода, им активно пользуются уже более чем в 150 странах мира и его популярность растет с каждым днем. Уже более 23 000 организаций по всему миру уже используют этот инновационный и надежный подход в своей практике и многие считают его лучшим методом управления проектами. Во многом это связано с тем, что PRINCE2 является действительно универсальным методом: он может быть применен к проектам в любой сфере деятельности и вне зависимо от различных условностей.

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

PRINCE2 -- основан на четком процессе, разбитом на 8 стадий и 45 подпроцессов. У каждой стадии есть свой набор целей, активностей, а также входных и выходных артефактов. Есть критерии, по которым можно судить о качестве артефактов. Они позволяют контролировать отклонения от качества в течение жизненного цикла проекта.

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

В сравнении с другими лучшими практиками и методами управления проектами, а именно PMBoK, PRINCE2 обеспечивает следующие преимущества:

Универсальность применения по отношению к любому типу проекта;

Единство терминологии и подходов;

Интегрируемость с другими практиками и со специфическими отраслевыми моделями и методологиями;

Фокус управленческих усилий на продукте проекта, в соответствии с согласованными стандартами качества;

Управляемость по отклонениям, с обеспечением эффективного использования времени руководителей;

Непрерывность внимания обеспечения жизнеспособности и целесообразности проекта;

Распределение ролей и зон ответственности участников.

Вывод: Применение PRINCE2 на практике характеризуется его функциональностью по отношению к различному уровню проектам. Построение внедрения услуг на подходах и знаниях PRINCE2 гарантирует понятность протекающего процесса, прозрачность и эффективность.

1.3.7 Capability Maturity Model Integration (CMMI)

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

Потребность в появлении данной методологии возникла в кулуарах Министерства обороны США с целью решения такого вопроса, как повышение качества разрабатываемого по заказу ПО. Разработкой модели, в соответствии с которой оценивались потенциальные исполнители заказов министерства обороны, занималась фирма Software Engineering Institute. В основу модели положен анализ процессов, выполняемых при разработке ПО, с учетом связанных с ними рисков.

Прообразом модели стала анкета, разработанная в 1987 году и содержащая всего 85 процессных и 16 технологических вопросов. По результатам ответов определялась принадлежность компании к одному из уровней зрелости. Со временем концепция уровней зрелости оставалась неизменной, но менялось число областей и их суть.

Уровень зрелости - итоговый показатель оценки по модели CMMI. Всего в модели представлено пять следующих уровня зрелости:

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

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

Третий уровень - определенный уровень. Все процессы описаны на уровне организации (но не на уровне отдельного проекта). Становится видимой внутренняя сторона черных ящиков.

Четвертый уровень - количественно-управляемый. Определенные процессы контролируются с помощью различных средств контроля. Самое главное отличие от третьего уровня - предсказуемая эффективность и управление ею с помощью средств контроля.

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

Кроме уровней зрелости, в методике есть понятие процессной области. CMMI состоит из 22 процессных областей, каждая из которых при внедрении задает цель. Некоторые из целей уникальны, некоторые применимы к нескольким областям, и таким образом их можно разделить на специальные и уникальные. Для достижения различных целей существуют практики, подразделяющиеся на общие и специальные. Список областей следующий:

· Менеджмент требований - управление требованиями к продуктам проекта.

· Планирование проекта - разработка и поддержание планов проекта.

· Мониторинг и контроль проекта - отслеживание стадий протекания проекта и корректировка в случае отклонения от плана.

· Измерение и анализ - поддержка измеримости услуг.

· Оценка качества товаров и процессов - управление качеством в соответствии с продуктом/товаром.

· Менеджмент договоров с поставщиками - управление внешними поставщиками.

· Конфигурационный менеджмент - контроль за целостностью продукции при обновлении и изменении.

· Разработка требований - сбор и анализ требований заказчиков к продукции.

· Техническое решение - разработка решений в соответствии с требованиями и их внедрение.

· Интеграция продукта - эксплуатация, проверка интеграции и функционирования введенного продукта.

· Верификация - соответствие продуктов требованиям.

· Валидация - соответствие продуктов использованию.

· Фокусирование на процессах организации - использование и понимание процессов в соответствии с областями деятельности.

· Описание процессов организации - установление и поддержание процессов организации.

· Организационный тренинг - повышение уровня знаний и развитие способностей людей для эффективного выполнения своих ролей.

· Менеджмент интеграции проектов - взаимодействие заинтересованных лиц при интеграции процесса.

· Менеджмент рисков - анализ возникновения чрезвычайных ситуаций до их возникновения.

· Интегрированные команды - формирование команд для разработки.

· Интегрированное управление поставщиками - мониторинг поставщиков и оценка новых источников ресурсов, использование собранной информации для выбора поставщика.

· Анализ решений и разрешение - анализ альтернативных решений и разработка наиболее подходящего решения на основе структурированного подхода.

· Организационная среда для интеграции - инфраструктура для процессов и интеграции продукта.

· Производительный организационный процесс - поддержание производительности процессов на эффективном уровне.

· Количественный менеджмент проекта - количественное управление определенным процессом в целях достижения качества и производительности.

· Организационные инновации и внедрение - анализ и выбор необходимых инноваций для внедрения.

· Анализ причин и разрешение - выявление причин дефектов и принятие превентивных мер по предотвращению их в дальнейшем.

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

1.3.8 eSourcing Capability Model for Service Providers (eSCM-SP)

eSCM-SP система, помогающая поставщикам ИТ-услуг развивать способности управления ИТ-услугами с точки зрения выбора модели предоставления услуг. Систему можно считать дополнением к существующей модели качества.

На рисунке 1.5 представлены основные направления: Sourcing life-cycle (стадии жизненного цикла), Capability levels (уровни способностей), Capability areas (область способностей) и 84 различных процесса, распределенных в соответствии с направлениями.

Рисунок 1.5 - Структура eSCM-SP

Система eSCM-SP предоставляет поставщику услуг необходимое руководство для предоставления качественных ИТ-услуг с необходимыми сервисами для клиента, а также обеспечивает клиентов средством оценки поставщиков услуг или сбором обратной связи с целью выведения поставщика на качественно новые показатели с обеспечением конкурентоспособности.

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

Существует пять уровней областей предоставления ИТ-услуг, поддерживающих следующие уровни зрелости организации:

· первый уровень - непосредственное предоставление услуг;

· второй уровень - наличие процедур, предоставляющих возможность соответствовать требованиям клиентов;

· третий уровень - организация полостью управляет своей работой;

· четвертый уровень - организация внедряет различные инновации;

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

Вывод: Система eSCM-SP рассматривается исключительно как дополнительная составляющая к международным стандартам, методам и подходам по управления ИТ-услугами. Ее применение на практике возможно только в том случае, если в организации существуют определенные методики по управлению ИТ-услугами и необходимо полностью обеспечивать клиента качественными сервисами.

1.3.9 SixSigmaR

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

В основу концепции заложены следующие основы:

· устойчивое и предсказуемое течение бизнес-процессов;

· ключевые показатели эффективности должны быть измеряемыми, контролируемыми и улучшаемыми;

· вовлеченность персонала для совершенствования качества продукции;

· клиентоориентированность;

· управление данными, факторами и показателями;

· постоянное совершенствование бизнес-процессов;

· взаимосвязанное взаимодействие внутри организации.

Для совершенствования процессов в SixSigmaR существует методика DMAIC (define - определение, measure - измерение, analyze - анализ, improve - улучшение, control - контроль), согласно которой процессы компании проходят через 5 этапов уровня зрелости.

Вывод: SixSigmaR позволяет обеспечивать выполнение управления производством на основе используемых стандартов, методик и практик. Использование возможно на определенном уровне зрелости

1.3.10 ISO 15504 или SPICE (Software Process Improvement and Capability Determination)

SPICE - эталонная модель, определяющая измерение процесса и измерение возможностей.

Модель разделена на процессы из пяти категорий: поставщик-потребитель, инжиниринг, поддержка, управление, организация.

Для измерения возможностей используется 5 уровней:

ь 5 уровень - оптимизированный процесс;

ь 4 уровень - предсказуемый процесс;

ь 3 уровень - установленный процесс;

ь 2 уровень - управляемый процесс;

ь 1 уровень - выполняемый процесс;

ь 0 уровень - неполный процесс.

Возможности процессов измеряются с помощью следующих атрибутов:

· производительность процесса;

· управление производительностью;

· управление продуктом;

· определение процесса;

· развертывание процесса;

· измерение процесса;

· контроль процесса;

· нововведения в процесс;

· оптимизация процесса.

· Not achieved (0 - 15%) - Не достигнуто.

· Partially achieved (>15% - 50%) - Частично достигнуто.

· Largely achieved (>50%- 85%) - В значительной степени достигнуто.

· Fully achieved (>85% - 100%) - Полностью достигнуто.

В стандарте описаны модель оценок в соответствии со следующими стандартами: ISO/ IEC 12207, ISO/ IEC 15288.

Вывод: Стандарт ISO/ IEC 15504 является одним из вспомогательных элементов способных обеспечить качественное предоставление ИТ-услуг.

1.3.11 ISO/ IEC 19770-1

Данная м етодология сосредоточена на оптимизации ИТ-процессов, состоящая из 27 областей процесса, описанных детально, с определенными для каждого процесса целями и результатами: SAM Processes -- сосредотачивает внимание на процессах SAM, реализация которых в организации необходима для эффективного управления программными активами.

Основа стандарта - четырехуровневый подход к внедрению ПО (рисунок 1.6):

Рисунок 1.6 - Четыре уровня ISO/IEC 19770-1

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

Рисунок 1.7 - Требуемые процессы для достижения оптимизации бизнес-процессов

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

1.3.12 ISO 38500

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

ISO/ IEC 38500 относится к управлению текущего и будущего использования ИТ организации, включая процессы и решения, связанные с текущим и будущим использованием ИТ-управления. Эти процессы могут контролироваться специалистами ИТ в рамках организации, внешними поставщиками услуг или бизнес-подразделениями в рамках организации.

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

Стандарт ISO/IEC 38500 обеспечивает соответствие деятельности организации обязательствам (законодательству, нормативным актам и контрактным соглашениям), обеспечивая при этом эффективное использование ИТ.

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

Структура стандарта ISO/IEC 38500:2008 содержит три раздела:

· область применения и цели стандарта, его применение;

· фреймворк хорошего корпоративного ИТ-управления;

· руководство по корпоративному ИТ-управлению.

Стандарт устанавливает шесть принципов корпоративного ИТ-управления:

· Ответственность (Responsibility). Ответственность сотрудников в организации в отношении потребления и предоставления ИТ-сервисов.

· Стратегия (Strategy). Учет современной и будущей стратегии и их связи с ИТ.

· Приобретение (Acquisition). Анализ поставщиков.

· Реализация (Performance). Поддержание и обеспечение качественного уровня услуг.

· Соответствие (Conformance). Соответствие ИТ законодательству и прочим нормативным актам.

· Поведение (Human Behaviour). Учет деятельности и нужд людей в ИТ-сфере.

В стандарте устанавленго три задачи управления для руководства организации в отношении ИТ:

· Оценка(evaluate) потребности в использовании информационных технологий.

· Направление (direct) планов и политики в сфере ИТ в соответствии с бизнес-целями.

· Контроль (monitor) соответствия политикам и исполнения планов.

Для повышения эффективности управление ИТ должно происходить логично и последовательно. Модель корпоративного управления ИТ (EDM - Evaluate -- Direct -- Monitor), отличается от привычного цикла PDCA.

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

1.4 Анализ методов моделирования диаграмм бизнес-процессов

Подходы к моделированию ИТ-процессов и существующие методы проектирования позволяют в полной мере обеспечить понимание протекающих внутри организации бизнес-процессов.

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

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

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

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

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

При объектно-ориентированном подходе корпоративная информационная система разбивается на объекты, взаимодействующие между собой посредством посылки сообщений.

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

Основу многих современных методологий проектирования диаграмм бизнес-процессов составляют:

· методология SADT (Structured Analysis and Design Technique) (IDEF0) - метод функционального моделирования;

· метод моделирования процессов IDEF3;

· моделирование потоков данных DFD;

· метод ARIS;

· метод моделирования, используемый в технологии RUP (Rational Unified Process).

1.4.1 Применение SADT (IDEF0)

Метод SADT (Structured Analysis and Design Technique) является классическим вариантом процессного подхода к управлению. В основу его принципа заложено структурирование деятельности организации в соответствии с ее бизнес-процессами, а не по тому как разработана штатная структура организации. Бизнес-процессы, протекающие внутри корпоративной информационной системы, выделяющиеся методом SADT и несущие в себе определенную ценность для организации должны оптимизироваться в первую очередь. Так же стоит упомянуть о том, что любой бизнес-процесс несет в себе информацию о том кому он предназначается и от кого он идет.

Метод SADT представляет собой совокупность правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

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

ИТ-процессы в нотации SADT имеют в своем составе бизнес-процесс с входными и выходными дугами, а также управленческие дуги и механизм.

1.4.2 Применение IDEF3

Подобные документы

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

контрольная работа , добавлен 20.02.2016


Подходы к определению понятия "моделирование бизнес-процессов". Классификация бизнес-процессов. Стандарт функционального моделирования IDEF0. Стандарт динамического моделирования IDEF2. Стандарт моделирования процессов IDEF3–IDEF14 и потоков данных DFD.

контрольная работа , добавлен 11.06.2010


Сущность бизнес-процессов и основные качественные и количественные критерии их оптимизации. Сравнительный анализ методологий моделирования бизнес-процессов, выбор программного средства на примере УУПП "Автоконтакт" ВОС; принцип автоматизации управления.

дипломная работа , добавлен 18.12.2012


Целесообразность внедрения процессного управления на ООО "Мир Алюминия". Разработка рекомендаций и механизма оптимизации основных бизнес-процессов как пути совершенствования системы управления на исследуемом предприятии. Моделирование бизнес-процессов.

дипломная работа , добавлен 08.01.2012


Характеристика взаимосвязи групп бизнес-процессов: основные, обеспечивающие и управления. Определение цели стратегического менеджмента как планирования поведения фирмы в отношении финансов, клиентов, бизнес-процессов, обучения и личностного роста кадров.

реферат , добавлен 12.09.2011


Исследование методологий описания бизнес-процессов, особенности оценки их эффективности. Информационные технологии моделирования бизнес-процессов. Разработка мероприятий по совершенствованию бизнес-процессов на примере швейной фабрики ООО "Бостон".

дипломная работа , добавлен 29.06.2015


Эффективное внедрение процессного подхода. Основные виды бизнес-процессов. Вопросы управления бизнес-процессами. Проект реинжиниринга бизнес процессов организации. Общая характеристика организации ООО "Мир стекла". Разработка бизнес-процесса организации.

курсовая работа , добавлен 17.11.2014


Понятие бизнес-моделирования. Анализ финансово-хозяйственной деятельности компании ЗАО "Ясень"; разработка бизнес-процессов производства, их оптимизация и повышение эффективности работы предприятия с внедрением программного продукта "1С:Молокозавод".

дипломная работа , добавлен 15.09.2012


Описание системы моделирования: обзор аналогичных систем, определение конвейерного бизнес-процесса, язык моделирования, редукция конвейера. Разработка методологии проектирования. Анализ проблем бизнеса и определение требований. Спецификация проекта.

дипломная работа , добавлен 07.07.2012


Рассмотрение сущности понятия бизнес-процессов, определение их места и роли на рынке. Описание систематизированных подходов к анализу бизнес-процессов. Разработка практических мер управления бизнесом в сфере социально-культурного сервиса и туризма.