Эффективное использование информационных технологий может стать одним из важных конкурентных преимуществ компании. Рассмотрим различные варианты организации и способы выбора оптимальной оргструктуры ИТ-подразделений.
Эффективное использование информационных технологий может стать одним из важных конкурентных преимуществ компании. Рассмотрим различные варианты организации и способы выбора оптимальной оргструктуры ИТ-подразделений.
Во многих компаниях сегодня внедряются или уже внедрены корпоративные информационные системы, поддерживающие эффективное выполнение бизнес-процессов. Однако для максимального использования возможностей информационных технологий необходимо, чтобы процессами развития и поддержки информационных систем занимались квалифицированные ИТ-специалисты. В большинстве случаев как только компания начинает использовать информационные технологии (хотя бы почту и офисные приложения), она сразу же нанимает ИТ-специалиста (в первую очередь системного администратора), который призван обеспечивать жизнеспособность информационных ресурсов компании.
Как сделать 1 МИЛЛИАРД на IT компании за 3 года? Герман Гаврилов
По мере роста компании и усложнения как физической ИТ-инфраструктуры, так и используемых информационных систем, штат ИТ-специалистов расширяется: появляются дополнительные системные администраторы и программисты (если возникают задачи по доработке используемого программного обеспечения или по разработке нового). Появляется необходимость взаимоорганизовать ИТ-специалистов, определиться с их функциями и соподчиненностью, собственно, встает проблема создания организационной структуры ИТ-подразделения.
Рассмотрим стандартную классификацию оргструктур в применении к ИТ-подразделениям.
1. Линейный — наиболее простой способ организации. Используется в небольших компаниях или на начальных этапах развития ИТ. Как правило, в этом случае выделяется должность руководителя отдела, в непосредственном подчинении которого находятся несколько ИТ-специалистов.
2. Функциональный способ организации — результат развития линейной структуры (см. рисунок). Собственно, этот способ сегодня является наиболее распространенным и служит основой для большинства других типов ИТ-оргструктур. Специалистов ИТ-отделов разделяют на подразделения на основе выполняемых функций.
Могут выделяться инженеры, программисты, аналитики, администраторы (сети, СУБД, отдельных информационных систем ). Сотрудников, как правило, делят на ведущих (главных) и просто специалистов.
3. Дивизиональный способ организации. Функциональной структуры может оказаться недостаточно, если компания состоит из нескольких крупных территориально-распределенных филиалов. В этом случае использование централизованной функциональной структуры может замедлить скорость решения задач отдельных филиалов.
Как правило, решением становится использование дивизиональной структуры ИТ-подразделения. По сути, это означает, что в каждом филиале создается ИТ-подразделение (со структурой близкой или идентичной структуре центрального офиса), в котором назначается руководитель.
КАК ОТКРЫТЬ IT БИЗНЕС. 5 шагов в IT от Михаила Токовинина. Артемий Лебедев выступит в марте 2019
При этом у сотрудников филиального подразделения может сохраняться функциональная подчиненность соответствующим руководителям подразделений центрального офиса. Минусом такой оргструктуры является увеличение руководящего состава в ИТ-структуре, усложнение администрирования распределенных ИС, так как получается, что за различные части этой системы отвечают сотрудники разных «дивизионов». Чтобы частично разрешить второй недостаток, используются также смешанные структуры, где основные ИТ-подразделения организуются на дивизиональной основе, но существуют отдельные подразделения ИТ, сохраняющие функциональную организацию, например, служба поддержки, организованная в центральном офисе, является единой для всех филиалов. Другие типы дивизиональных структур — по клиенту или по продукту — в ИТ применяются значительно реже. Примером дивизиональной структуры по продукту может служить выделение отделов в ИТ-подразделении по отдельным крупным информационным системам (отдел сопровождения ERP-системы, например).
Рассмотренные виды оргструктур ИТ являются типовыми и им всем присущ недостаток, связанный с низкой адаптивностью и медленной реакцией на изменения в бизнесе. Впрочем этот недостаток на уровне ИТ-подразделений может и не оказать какого-либо негативного воздействия на бизнес в целом. Во многих случаях функциональная и дивизиональная структуры обеспечивают эффективную поддержку бизнеса. Однако если речь идет не только об обеспечении работоспособности ИТ-инфраструктуры, но и о ее постоянном развитии в соответствии с потребностями бизнеса, то компания должна использовать адаптивные оргструктуры ИТ-подразделений.
Классический подход выделяет два типа адаптивных оргструктур: проектную и матричную. В применении к ИТ-подразделению, проектная структура означает, что компания привлекает внешних специалистов для решения определенных задач развития — например, выбора и внедрения какой-либо информационной системы. После завершения проекта эти специалисты покидают компанию или принимают участие в новых проектах. Такая структура очень полезна в период интенсивного развития ИТ-инфраструктуры компании. Действительно, зачем на постоянной основе увеличивать штат ИТ-специалистов, если для выполнения проекта можно взять временных сотрудников?
Развитием проектного подхода является матричный подход. Матричная схема организации ИТ-оргструктуры предполагает наличие функциональных подразделений (функциональная оргструктура), из сотрудников которых периодически формируются проектные команды (проектная оргструктура) с возможным привлечением внешних специалистов.
Такая организация является, пожалуй, наиболее эффективным способом использования всех имеющихся компетенций сотрудников для достижения поставленных задач развития ИТ-инфраструктуры. Её минусом является требование четкой регламентации взаимодействий между участниками проектной команды и линейными сотрудниками, так как возможно возникновение конфликтов «подчинения», когда, с одной стороны, сотрудник должен выполнять поручение своего линейного руководителя, а с другой, активно участвовать в проекте. Однако, эти вопросы вполне могут быть урегулированы. Также необходимым условием успешного использования матричной оргструктуры является высокая квалификация менеджеров проектов и эффективные схемы мотивации сотрудников к выполнению проектов. Недостатком матричного подхода к организации ИТ является то, что он направлен именно на реализацию проектов по развитию ИТ-инфраструктуры и плохо применим к задачам ее постоянной поддержки и анализа (эти задачи реализуются в рамках функциональной оргструктуры).
Для того чтобы повысить эффективность выполнения всех задач ИТ-подразделений, используется процессный подход к организации деятельности ИТ, когда утверждается менеджер процесса, которому должны подчиняться все участники. В этом случае можно говорить о процессной оргструктуре ИТ-подразделения. Однако, многие сотрудники принимают участие в нескольких процессах.
Так, если говорить об организации процессов в соответствии с методологией ITIL, то сотрудники службы поддержки регистрируют и сообщения о сбоях (процесс управления инцидентами), и запросы на изменения (процесс управления изменениями). Часто один сотрудник может выполнять роль менеджера различных процессов, например, менеджера по изменениям и по релизам. Из этого следует вывод, что нельзя просто выделить отделы в соответствии с процессами.
Таким образом, на практике процессная структура (роли) накладывается на существующие функциональные структуры, образуя функциональную оргструктуру с процессным взаимодействием, которая также требует четкой регламентации взаимодействия между сотрудниками. В этом случае каждый сотрудник может иметь несколько руководителей — непосредственного начальника, руководителя проекта, в котором он принимает участие, и менеджеров процессов.
Понятно, что для отдельного сотрудника становится затруднительно определить, что же он делает, в каком порядке и кому подчиняется. Для упрощения этой ситуации возможно управление проектами также рассматривать в рамках процессного подхода. Например, выделяется процесс «Развитие ИТ», в рамках которого реализуются проекты.
Менеджер этого процесса является также директором портфеля проектов по развитию, и ему «процессно» подчиняются менеджеры отдельных проектов по развитию. Конечно, такое упрощение является в некоторой степени условным, так как процесс выполняется на постоянной основе, а менеджер проекта имеет полномочия только во время осуществления проекта, но, тем не менее, такой подход может быть использован при условии четкой регламентации всех взаимодействий, как говорилось ранее.
В этом случае остается только две «линии воздействия» на сотрудника — от менеджера процесса и от линейного руководителя. И здесь, конечно, многое зависит от того, как тщательно спроектированы процессы и насколько корректно произведено наложение процессной структуры на линейную структуру ИТ-подразделения.
Обычно такое наложение стремятся сделать таким образом, чтобы существовало минимальное количество противоречий, хотя полностью их не избежать. При этом важно учитывать, что по процессному принципу обычно организуется только часть функциональности ИТ-подразделения. Так, могут не затрагиваться задачи, связанные с системным администрированием. Поэтому наиболее корректным вариантом является сочетание принципов процессного взаимодействия (динамика) и функционально-дивизиональной организации (статика).
Говоря об оргструктуре ИТ-подразделения, нельзя не упомянуть и вариант ИТ-аутсорсинга, так как от степени его использования в компании сильно зависит организация ИТ-подразделения. В последние годы наблюдается тенденция перехода компаний на аутсорсинг отдельных процессов ИТ.
Как правило, это крупные предприятия, которые столкнулись с тем фактом, что обеспечить эффективную организацию и функционирование собственного ИТ-подразделения сложнее, чем приобретать эти услуги у внешнего поставщика. Действительно, если большинство процессов находится на ИТ-аутсорсинге, то задачей подразделения ИТ в составе компании становится заключение соответствующих договоров и контроль над их реализацией. Тем не менее, сам по себе аутсорсинг достаточно дорогое удовольствие и переходить на него нужно постепенно, так как вернуться к использованию собственной ИТ-структуры будет сложно. В соответствии с современными методологиями (ITSM) принципы взаимодействия с собственным и внешним ИТ-подразделением мало отличаются друг от друга. Собственное ИТ-подразделение также рекомендуется рассматривать как поставщика ИТ-сервисов, которые оно предоставляет бизнес-пользователям.
Существует множество параметров, определяющих выбор оргструктуры. На верхнем уровне их можно условно разделить на три группы:
- параметры оргструктуры компании («люди»);
- параметры ИТ-инфраструктуры («технологии»);
- параметры зрелости ИТ-процессов («процессы»).
Рассмотрим каждую группу подробнее.
1. Параметры оргструктуры. К этой группе относятся параметры, характеризующие оргструктуру компании, — количество филиалов, их территориальная удаленность, схема управления филиалами, количество их сотрудников.
2. Параметры ИТ-инфраструктуры. К этой группе относятся параметры, определяющие ИТ-инфраструктуру компании, соотношение ПО собственной и внешней разработки, степени критичности используемого ПО для бизнеса, полнота автоматизации бизнес-процессов. Критичность ИТ для бизнеса определяет и требования к уровню зрелости ИТ-процессов.
Условно критичность можно понять следующим образом — если ваши ИС не будут работать в течение 3-х часов, какие потери понесет бизнес? Ответ на этот вопрос позволяет определить, насколько важно для вашей организации обеспечить бесперебойность работы информационных сервисов.
3. Параметры зрелости ИТ-процессов. Данная группа включает в себя параметры, характеризующие уровень зрелости каждого из ИТ-процессов компании.
Анализируя перечисленные выше параметры, можно выбрать наиболее эффективную организацию ИТ-подразделения, а также последовательность шагов по реорганизации ИТ. При этом, первые две группы параметров определяют штатную структуру ИТ-подразделения, а третья группа показывает точное распределение функций между сотрудниками ИТ-подразделений, а также способ организации взаимодействия между ними. Если речь идет о компании со штатом до 60 сотрудников, то рекомендуется использовать линейную схему организации ИТ.
Если речь идет о многофилиальной организации, где более 150 сотрудников, то рекомендуется использовать смешанный дивизиональный подход, когда в отдельных филилах, по сути, используется линейно-функциональная организация. При этом общие ИТ-функции управления и контроля реализуются в центральном офисе.
По мере повышения уровня зрелости ИТ-процессов все больший уклон в компаниях делается в сторону процессной организации ИТ. Большими полномочиями начинают обладать менеджеры в рамках собственных процессов, а не линейные руководители ИТ-отделов. Хотя руководитель отдела во многих случаях будет являться менеджером соответствующего ИТ-процесса. Эмпирические рекомендации приведены в таблице.
Таким образом, если эффективность и надежность ИТ-инфраструктуры критичны для нормального функционирования бизнеса, то в большинстве случаев рекомендуется организовывать ИТ-подразделения в соответствии с принципом процессного взаимодействия, например, на основе методики ITIL, которая определяет подходы к наиболее эффективному выполнению ИТ-процессов. Следует, однако, подчеркнуть, что ITIL не определяет требований к организационной структуре ИТ-подразделения, а только выделяет роли, которые должны быть распределены в ней.
Рекомендуется проводить оптимизацию оргструктуры ИТ-подразделения вместе с анализом и оптимизацией ИТ-процессов компании. Проектирование оргструктуры ИТ всегда зависит от состава функций и/или процессов ИТ-подразделения (особенно сильна эта зависимость в оргструктурах с процессным взаимодействием). Поэтому наибольший эффект компания может получить, если при проектировании оргструктуры основывается на регламентированных и эффективных ИТ-процессах.
Источник: www.osp.ru
Об оргструктуре и бюрократии
Не так давно [около года — именно столько времени пролежала статья «в столе»] сидели мы с товарищем и думали за вопросы организации ИТ-компании. В реально большой ИТ-шной компании мы не работали, вся жизнь прошла в ИТ-подразделениях организаций, для которых ИТ — не основной вид бизнеса. Так что, хотя об организационной структуре мы представление имеем, с деталями её применения к приличных размеров конторе, чья жизнь — реализация и сопровождение софта, мы не знакомы.
Получилась после двух часов раздумий у нас примерно такая картинка, основные положения которой поясняются под катом.
Введение
Итак, у нас есть организация, которая ведёт достаточно крупные ИТ-проекты, внедряет их по стране, и много времени тратит на их поддержку. Также, из вводных, предполагаем, что бухгалтерия отдаётся на аутсорс.
Тут также имеет смысл упомянуть, что специфика в поддержке больших баз данных и систем обработки этих данных — есть уже несколько работающих решений, которые надо поддерживать.
- Написание техзадания по списку техтребований и согласование их с заказчиком;
- создание полноценной технической документации (так как мы ориентируемся на последующее сопровождение проектов);
- проработка методологического и математического обеспечения;
- разработка архитектуры решения;
- создание софта;
- тестирование;
- внедрение;
- сопровождение.
Описание структуры
Каждый пункт это, фактически, отдел, хотя некоторые имеет смысл сложить вместе. Например, выпускное тестирование имеет смысл объединить с техдокументацией, а внедрение — с сопровождением.
- Для отдела тестирования и технического документирования:
- интеграционное тестирование фактически проверяет программу на соответствие спецификации, т.е. техническому проекту;
- правильно определённая методика выпускного тестирования выявит не только фактические, но и логические ошибки — то есть когда программа не падает, но результат отличается от спроектированного;
- написанный софт выглядит как чёрный ящик, что позволяет абстрагироваться от его внутренностей;
- Для отдела внедрения и сопровождения:
- налаживаются контакты представителей техподдержки и представителей заказчика, так как внедрение и сопровождение «в одном флаконе»;
- «нулевое внедрение» производится на площадке тестировщиков, что позволит обкатать различные сценарии установки и получить боевой опыт дома.
С разработкой всё проще, есть отдел разработки системного и прикладного ПО, отдел веб-технологий, и выделен (так как большой объём работы с БД) отдел работы с БД.
Что касается разработки техзадания и заключения договоров — это типичные такие менеджеры, которые работают по проектному принципу с задачей «договориться с заказчиком, выдать задачи исполнителям, и следить чтобы всё было по графику». Директор наверняка будет с нетерпением ждать этих орлов в кабинете каждый отчётный период и ни за что не делегирует возможность дать им разгон своему заму.
Есть ещё пара пунктов, с которыми не совсем понятно. Это проработка математического обеспечения и разработка архитектуры софта.
Задача отдела матобеспечения — сформулировать методики, написать формулы, проработать методологию бизнес-процессов у заказчика. Этакий пул экспертов, досконально разбирающийся в теме, готовый дать решение по любому концептуальному вопросу.
Отдел проектирования ПО же, скорее, должен заниматься проработкой концептуальной целостности продукта, давать для отдела разработки скелет, который необходимо обтянуть мясом. Как проектный офис — место, где сидят менеджеры, так и отдел проектирования ПО — место, где сидят тимлиды.
Обе задачи не относятся ни к производственной, ни к операционной деятельности. Скорее, это некие отделы НИР, которые смотрят вперёд, собирают оптимальные решения, применяют их на практике и руководят разработкой.
Таким образом, получаем три ветки — развитие, разработка и техподдержка. Каждый проект проходит стадию инициации в проектном офисе, концептуальной проработки в департаменте развития, написания техдокументации в операционном департаменте, разработки, и затем передаётся опять в департамент сопровождения для внедрения.
Такой путь проекта теоретически должен позволить выявить концептуальные недостатки и фактические ошибки внутри организации, не вынося их к заказчику.
Тут требуется сделать небольшое лирическое отступление.
Давайте быстренько автоматизируем это!
В 2007м году поступило совершенно неформализованное задание «сделать им хорошо». После выяснения, кому именно и как именно надо «сделать хорошо», родился здоровый документ, в котором было всё это написано. Путь согласования документа, прямо скажем, был тернист и извилист, и учитывал интересы всех. Сейчас я понимаю, что, если это всё написать, получилась бы если не 1С, то что-то похожее; тогда мне это было совершенно неочевидно. «Ладно, — подумал я, — фигня, где наша не пропадала. » — и сел за работу. Месяца через четыре был готов какой-то прототип, и я поехал его сдавать.
Выяснилось, что всё не так: то неудобно, это неверно, тут вообще бизнес-процесс поменялся… ну, в общем, я думаю, все могут представить эту ситуацию. Крякнув, я снова сел за работу.
Через несколько итераций (и после отвлечения на написания регламентов и изменение концепции) программа была принята, а ещё через несколько месяцев внедрена и встала на боевое дежурство. К тому времени вследствие изменения внутренней структуры организации, изменения приоритетов и т.п., 75% написанного изначально ТЗ потеряла актуальность. Но это, на самом деле, не проблема.
Проблема в том, что в погоне за скоростью написания софта все эти изменения не документировались. Соответственно, в настоящее время (да-да, оно до сих пор работает, что удивительно) софт может сопровождать ровно один человек, то есть я. А так как договора на сопровождение нет, то писать мне какие-то документы резона никакого нет (да и сам софт на дельфях). В результате раз в год они мне звонят, я правлю какие-нибудь мелочи сроком не более чем на неделю, и забываю об этом софте ещё на год.
Передать такое на поддержку куда бы то ни было принципиально невозможно. И именно эта история меня принудила предложить схему разделения ответственности между написанием техпроекта и софта, а также между написанием софта и его внедрением.
Возвращаясь к оргструктуре
Итак, в нашей идеальной структуре потенциальные ошибки, подобные описанным в предыдущем пункте, должны будут фильтроваться дважды — при передаче документа от техписателей и при передаче софта внедренцам. Каждый срыв срока — предмет для разбирательства глав департаментов и менеджера проекта. Это совершенно чёткие вехи, от которых зависит проект. Более того, процессы с каждой стороны вех контролируются разными департаментами, что позволяет избегать размытия ответственности и передачу «на честном слове».
Производственная часть есть. Осталось добавить финдиректора, отдел АХО, юристов и эйчарню, и оргструктура нашей ИТ-компании готова.
О составе проектной команды
Состав формируется как «представители отдела разработки под предводительством крутого специалиста из отдела проектирования ПО при поддержке методолога из группы матобеспечения под чутким контролем менеджера старательно удовлетворяют заказчика». Так что такой подход позволяет использовать не только «классический» водопад, но и гибкие технологии, где менеджер выступает как product owner. Единственно, это требует небольшого оверхеда на обратную связь с отделом технической документации, что не должно очень уж сильно тормозить процесс.
Единство и борьба противоположностей
- Зам. директора по развитию — увлекающийся, с широким кругозором, всегда стремится к новым знаниям, новым технологиям. Его департамент почти всегда работает в чистый минус, но идеи, рождающиеся в нём, дают пищу остальным отделам, двигая компанию вперёд. Убеждённый оптимист.
- Зам. директора по операционной деятельности — осторожный, опытный работник, видящий всё на три шага вперёд, и потому скорее пессимист, хотя чаще всего обзываем ретроградом. Его департамент приносит стабильный, но небольшой доход, и он не хочет, чтобы из-за новых веяний инноватора всё пошло прахом.
- Зам. директора по производству — самый уравновешенный из всех, первый заместитель. Служит балансиром между инноватором и традиционалистом, придерживается эволюционной теории. Он приносит большую часть прибыли, обеспечивая всех бонусами, а директора — новой машиной, а потому спокоен.
- Финансовый директор — считает доходы и расходы и время от времени мягко напоминает инноватору, что если так пойдёт дальше, то директор не получит свой ежегодный порш кайен, а все остальные — свой бонус.
Заключение
Так как я ни разу не управленец, а данная схема и обоснование — всего лишь плод размышлений «на тему», сильно прошу не бить ногами, а лучше высказать дельные замечания и конструктивную критику, которые весьма могут пригодиться другим.
- сервис
- управление проектами
- организация работы
Источник: habr.com
Энсис Технологии
Для успешного достижения целей и реализации задач, стоящих перед ИТ-службой, нужно правильным образом выстроить ее структуру и операционную модель деятельности. Какие структурные единицы следует включить в состав ИТ-службы и как организовать их деятельность максимально эффективно? В данной статье мы не ставим цель описать идеальную оргструктуру. Наша задача — оговорить ключевые аспекты, которые необходимо учесть при построении оптимальной базовой структуры ИТ-службы.
Два вида деятельности: поддержка и развитие
Деятельность любой ИТ-службы или ИТ-департамента состоит из двух частей: поддержка существующих ИТ-услуг и развитие, то есть создание новых, модернизация существующих ИТ-услуг в соответствии с запросами бизнеса. Это два основных направления деятельности, в той или иной пропорции представленные в ИТ-подразделениях любых компаний.
Под поддержкой понимаются именно процессы, обеспечивающие должное качество ИТ-услуг, «потребляемых» бизнесом. И здесь мы будем говорить о применении лучших мировых практик (best practice) для организации деятельности ИТ-службы, таких как ITIL/ ITSM.
Вторая часть — развитие и создание новых услуг по запросам бизнеса или в связи с появлением новых технологий — относится к проектной деятельности, то есть для обеспечения данной работы необходимо сформировать в структуре ИТ-департамента проектный офис и создавать новые услуги в рамках проектов.
ИТ-служба как бизнес
При выборе структуры ИТ-службы и разработке операционной модели ее деятельности для достижения оптимальности и эффективности целесообразно рассматривать ИТ-службу как отдельный самостоятельный бизнес. И в этом случае нет необходимости искать какие-то уникальные решения по организации ее работы. ИТ-служба — точно такой же бизнес, как и любой другой. Подходы к построению любого бизнеса уже давно выработаны.
С данной точки зрения основными структурными блоками ИТ-службы, как и любой коммерческой компании, будут производственное подразделение и продажи. То есть мы должны сначала произвести товар, в данном случае ИТ-услугу, а потом продать ее бизнес-подразделению на определенных условиях.
С другой стороны, при организации деятельности ИТ-службы целесообразно обратить внимание на лучший мировой опыт компаний, накопленный в данной сфере. За последние годы российской ИТ-индустрией пройден большой путь, вслед за остальным миром все больше отечественных компаний используют в своей работе ITIL/ITSM, что позволяет компаниям, во-первых, четко описать те услуги, которые требуют поддержки (сервисная ориентированность), а во-вторых, измерить процессы поддержки (процессный подход).
Но прежде чем мы перейдем к более подробному рассмотрению принципов построения ИТ-службы с учетом практик ITIL/ITSM, стоит сделать акцент на следующем важном принципе: нельзя сначала строить структуру, а потом создавать процессы, равно как и наоборот. Этим надо заниматься одновременно, сразу строя такую структуру, в рамках которой процессы будут жизнеспособны и эффективны. Поэтому в дальнейшем мы нередко будем совместно затрагивать и вопросы организационной структуры, и особенности процессов, в которые эти оргструктуры вовлечены.
Остановимся на деятельности ИТ-службы, касающейся поддержки. Опираясь на подход к ИТ-службе как к бизнесу, рассмотрим в первую очередь так называемые «продажи».
Для организации этой деятельности ключевым процессом ITIL/ITSM является процесс управления уровнем услуг. Реализация процесса требует тесной работы с бизнес-заказчиком этих услуг. Если вы хотите контролировать и гарантировать качество услуг, предоставляемых бизнесу, и откликаться на его новые запросы, то в составе ИТ-службы необходимо создать службу заказчика — команду менеджеров, которые всегда будут готовы ответить на все вопросы и отчитаться за качество предоставляемых услуг. В крупных компаниях такое подразделение, как правило, существует. В небольших компаниях это может быть отдел, занимающийся контролем за обязательствами ИТ-службы по предоставлению услуг и работой с бизнесом по приему и анализу запросов на предоставление новых услуг.
Базовый принцип работы службы заказчика — согласование возможностей ИТ-службы и потребностей бизнес-подразделений. Таким образом, первые шаги, которые необходимо сделать при разработке структуры ИТ-службы, — провести ревизию и создать каталог услуг, а также определить критерии качества, предъявляемые к этим услугам. Эта трудоемкая работа — тот самый краеугольный камень, «заложив» который, мы можем сформировать требования как к ресурсам, так и к структурам, необходимым для поддержания этих услуг.
После определения каталога услуг и понимания, что же мы предоставляем (продаем) бизнесу и что ему нужно, мы можем определить задачи службы заказчика и ее внутреннюю структуру. С одной стороны, служба заказчика должна отслеживать нужды и потребности заказчиков, поэтому в ее структуре должно быть подразделение, занимающееся именно управлением услуг для конкретных заказчиков (по аналогии с аккаунт-менеджером любой коммерческой компании). Это подразделение должно работать с конкретными заказчиками и службами, использующими ИТ-услуги; следить как эти ИТ-услуги предоставляются; оказывать дополнительные услуги из имеющегося каталога услуг и отчитываться об их качестве.
С другой стороны, в структуре службы заказчика необходимо подразделение, которое работает и с «производственным подразделением» нашей ИТ-службы: предъявляет требования по качеству ИТ-услуг и контролирует их качество.
Таким образом, для производственного подразделения служба заказчика выступает в роли заказчика, а для бизнес-подразделения — в роли поставщика, продавца услуг. Будучи промежуточным звеном, служба заказчика фактически является переводчиком, владеющим языком бизнеса и языком технологий.
Теперь остановимся на работе производственного подразделения более подробно. Во-первых, определим, что под данным термином мы понимаем сервисную службу, которая занимается предоставлением и поддержкой ИТ-услуг.
Производственная инфраструктура поддержки ИТ-услуг в соответствии с лучшими практиками должна иметь поддержку диспетчерской службы – службу HelpDesk, которая будет служить единой точкой обращений для всех поддерживаемых пользователей и одновременно точкой регистрации всех работ по этим обращения и центром координации деятельности по поддержке.
Руководитель HelpDesk должен подчиняться непосредственно руководителю ИТ-департамента, а сама служба обязательно должна быть независимой от других функциональных подразделений, занимающихся собственно поддержкой ИТ-услуг. Будучи независимой, служба HelpDesk обеспечивает координацию их деятельности: отправляет запрос на исполнение в необходимое функциональное подразделение и имеет возможность проследить ход выполнения запроса, фиксируя все этапы работ.
В части функциональной организационной структуры производственного подразделения давать какие-то универсальные рекомендации нет необходимости — эта структура определяется имеющимися/требуемыми предметными компетенциями, которые, в свою очередь, определяются перечнем поддерживаемых ИТ-услуг.
Необходимо лишь отметить, что для оптимальной организации процессов ИТ-поддержки все функциональные подразделения компании стоит выстроить в линии поддержки так, чтобы каждая последующая линия состояла из специалистов более высокой квалификации. Это позволит большинство запросов, не требующих высокой компетенции, отрабатывать на первых линиях поддержки и не тратить время более квалифицированных и дорогостоящих сотрудников.
В соответствии с международными рекомендациями ITIL/ITSM о выстраивании процессного подхода, в рамках производственного подразделения должны быть реализованы следующие процессы :
управления инцидентами,
управления изменениями,
управления проблемами,
управления конфигурациями.
Над этими процессами поддержки ИТ-услуг существует еще один главенствующий процесс, завершающий это посторение — процесс управления уровнем услуг, который «пронизывает» всю ИТ-службу, включая, как мы уже оговаривали выше, службу заказчика. Для того чтобы процесс управления уровнем услуг работал эффективно, должны быть выстроены и все упомянутые выше процессы поддержки ИТ-услуг.
Внедрение процессов поддержки предполагает, что каждый процесс должен быть закреплен за определенным менеджером, контролирующим качество его исполнения. Менеджеры каждого из процессов поддержки ИТ-услуг не должны входить ни в одно функциональное подразделение, включая саму службу HelpDesk. Но при этом они должны находиться в составе производственного подразделения, будучи своеобразным штабом его руководителя.
Организационная структура, в которую входят менеджеры процессов поддержки, может иметь разные названия. Важно, чтобы эти сотрудники были выделены из функциональных подразделений, подчинялись непосредственно руководителю производственного подразделения и отвечали за работу процессов. В свою очередь, все руководители функциональных подразделений (отделов) в части процессной деятельности должны быть подчинены менеджерам этих процессов.
Выше мы подробно оговорили процессы поддержки. Обратим внимание на вторую часть деятельности, которую вынуждена вести ИТ-служба компании — развитие ИТ-инфраструктуры, создание и внедрение новых, модернизация старых ИТ-услуг. Эта деятельность подчинена проектному принципу управления и требует наличия так называемого проектного офиса. При этом проектный офис входит в службу заказчика, а в его задачи входит управление отдельными проектами и портфелем проектов. (Под портфелем проектов понимается совокупность ведущихся проектов и имеющихся инициатив на разработку новых услуг.)
Отнесение проектного офиса к службе заказчика не случайно и носит принципиальный характер. Управление портфелем корпоративных проектов — это, в первую очередь, постоянный процесс определения приоритетов и инвестирования в проекты в соответствии с корпоративной стратегией. То есть, прежде чем решать вопрос об одновременной реализации десяти, двадцати или пятидесяти проектов, необходимо ответить на вопрос: а надо ли их вообще реализовывать?
В первую очередь необходимо оценить достигаемый эффект, риски при достижении этого эффекта и все необходимые затраты — проанализировать требования бизнеса и критичность этих требований. Именно поэтому проектный офис должен находиться в службе заказчика, а решение о необходимости ведения того или иного проекта должно приниматься совместно с бизнесом. Таким образом, первая решаемая задача — не пытаться внедрить все проекты любым способом, а «выбросить» все те, что по той или иной причине делать не надо. А уже потом выстроить управление проектами оптимальным образом.
Важно отметить, что, помимо участия в процессах поддержки ИТ-услуг, производственное подразделение также вовлечено в проектную деятельность. Инициаторами и руководителями проектов выступают проектный офис службы заказчика. Однако исполнителями проектов или проектными ресурсами служат, в том числе, сотрудники производственного подразделения. Следовательно, одной из основных проблем при организации единого ИТ-департамента является общность ресурсов, вовлеченных и в поддержку, и в проектную деятельность. И здесь очень важно грамотно организовать структуру и наладить работу, позволяющую разрешать этот конфликт.
В рамках процессов поддержки при распределении задач необходимо учитывать текущую загрузку сотрудников по проектам. Для этого руководители функциональных подразделений, распределяющие загрузку по процессам поддержки, должны иметь доступ к системе управления проектами для анализа текущей загрузки своих сотрудников.
При этом за распределение времени сотрудников между проектной деятельностью и деятельностью по поддержке отвечает руководитель производственного подразделения, который одновременно является менеджером ресурсов. Руководителю необходима система сквозного учета рабочего времени и планирования ресурсов — он должен иметь возможность сквозного учета трудозатрат как по процессам поддержки, так и по процессам проектной деятельности. Именно он должен принимать и расставлять приоритеты работ.
На всех этапах построения структуры эффективной ИТ-службы следует помнить: какие бы построения мы ни делали, без должной автоматизации все они — утопия. Если мы хотим регламентировать процесс, необходим инструмент, который жестко требует от персонала исполнения всех процессных требований.
Инсорсинг и аутсорсинг
Рассмотренная структура ИТ-службы, на наш взгляд, достаточно универсальна. В настоящее время тенденцией на рынке является активная передача ИТ-услуг на аутсорсинг, и рассматриваемая нами структура легко и удобно это допускает.
Где же проходит та самая граница отчуждения, по которой мы можем «разбить» существующую ИТ-службу и часть ее отдать внешней организации? Она лежит между службой заказчика и производственным подразделением. Последнее может быть как внутренним департаментом, так и внешней компанией, работающей со службой заказчика по сервисным договорам. Служба заказчика в любом случае остается в составе компании, так как именно она понимает и трансформирует запросы бизнеса в конкретные технологические услуги, и уже эти услуги заказывает во внешней организации или внутреннем подразделении.
В рассмотренной нами оргструктуре допускается появление смешанной модели, когда одна часть услуг предоставляется внутренним производственным подразделением, а другая – внешними сервисными организациями. Таким образом, предложенная нами структура подходит для моделей как инсорсинга, так и аутсориснга, а также для смешанной модели.
Рассмотренная нами структура может показаться сложной и применимой лишь в достаточном масштабной компании. Конечно, если в вашей ИТ-службе работают всего три-четыре человека, то наши рекомендации будут избыточными. Но важно понимать следующее: какой бы сложности и масштаба ни была структура, основные функции и виды деятельности ее ИТ-службы, которые мы упоминали, остаются неизменными. Выбор оптимальной структуры для каждой конкретной организации — это всегда задача конкретного проекта и анализа.
Для достижения целей и реализации задач, стоящих перед ИТ-службой любого масштаба, необходимо, во-первых, работать с заказчиком и выполнять те функции, которые мы рассмотрели в части организации работы службы заказчика. Во-вторых, оптимально и качественно осуществлять поддержку услуг в соответствии с нуждами заказчика — то, что мы рассмотрели в рамках организации работы «производственного подразделения. В-третьих, предусмотреть возможность не только поддержки ИТ-услуг, но и развития новых услуг — об этом мы говорили в части построения работы проектного офиса службы заказчика.
Для успеха в работе все перечисленные виды деятельности необходимо организовать в рамках ИТ-службы независимо от размеров вашей компании. Разумеется, сложная структура нужна не всем, но в любом случае необходимо отталкиваться от базисных аспектов и распределить все упомянутые функции между существующими сотрудниками, даже если их пока всего три человека. Когда компания в дальнейшем будет расти, то изначально определенная структура будет просто «добираться» количеством людей и расширяться до отдельных служб и отделов, при этом сохраняя свою оптимальность и эффективность.
- Задать вопрос эксперту
- Написать сообщение
Источник: www.topsbi.ru