Июньский номер IT Manager вышел с моей статьей "Практика внедрения проектного управления за 10 шагов" (https://www.it-world.ru/cionews/management/139512.html)

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

В майском номере моего любимого журнала ITManager вышла моя очередная статья - "Кое-что из практики оптимизации бизнес-процессов". (https://www.it-world.ru/cionews/management/138982.html) Поделился опытом в области оптимизации бизнес-процессов :)

Вышла моя статья "Про дисциплину, самоконтроль и мотивацию" в ИТ-менеджере: http://www.allcio.ru/cionews/want/137623.html

Долгострой, писал ее аж с середины 2016 года, пару раз переписывал "начисто". Но очень доволен тем что закончил, так как сформулировал все так как хотел.

Буду рад обратной связи :)

Вышла моя статья "С широко закрытыми глазами" (http://www.allcio.ru/cionews/want/136676.html)

Она про 5 ошибок проектного и не очень бизнеса. Как говорится, прошу любить и жаловать :)

Вышел майский номер журнала ИТ-менеджер, с моей статьей "Про планирование в проектах".

В некотором смысле - "собрал опыт в кучу, систематизировал и поделился".

А вообще давно я не писал про свои статьи (а статьи, что характерно - писал).

Не знаю, в курсе уважаемые читатели, или нет - но в общем, я наверное, уже лет так 10 пишу статьи. А последние лет 6 - пишу их не на "технарские" темы (все же "технарь" - это хобби), а на тему отношений ИТ и бизнеса, проектного управления, SLA... Подумал, что вообще-то получается, что я пишу в журнал, как в блог. Да, я пишу в журнал, который называется IT Manager. Более того, являюсь членом экспертного совета этого журнала. В общем, все достаточно серьезно. 

Публикую статью "ITIL: необходимо и достаточно", которая была опубликована в журнале "Системный Администратор" (www.samag.ru) от 11.2008 - дело в том, что по соглашению с редакцией, публикация статьи возможна через три месяца после ее издания; кроме того, на публикацию этой статьи получено разрешение от редакции, так что все формальности соблюдены. Итак,

ITIL: необходимо и достаточно?

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

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

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

История возникновения

Сама идея управления ИТ как бизнесом не нова. Уже в 80ых годах прошлого века по заказу британского правительства Центральное агентство по вычислительной технике и телекоммуникациям (Central Computer and Telecommunications Agency, CCTA) разработало принципы управления ИТ, позволяющие, с одной стороны, использовать имеющиеся ИТ ресурсы максимально эффективно, а с другой - эксплуатировать ИТ с минимальными затратами. Результат выполнения заказа представлял собой свод лучших практик в отрасли, и назывался «библиотекой ITIL (Information Technology Infrastructure Library)». Библиотека ITIL называется библиотекой потому, что состоит из ряда книг, содержащих обобщение практического опыта, так называемые best practiks - лучшие практики отрасли. В 2001 году CCTA вошло в состав OGC (Office of Government Commerce), и с тех пор развитие ITIL осуществляется OCG. В том же году вышла вторая версия библиотеки ITIL.

Основы ITIL

По замыслу разработчиков, ITIL представляет собой практическое расширение сервисного подхода на область информационных технологий (ITSM - information technology service management), основная идея которого состоит в том, что ИТ подразделение предоставляет основному бизнесу не нечто абстрактное, а конкретные сервисы конкретному внутреннему заказчику, для которых определены метрики качества, и с потребителями которых  заключено соглашение об уровне сервиса (SLA - Service Level Agreement).

Для того, чтобы понять эту идею, приведём конкретные примеры. Предположим, есть организация, занимающаяся подбором персонала через Интернет. Для менеджеров, которые осуществляют подбор, установлены следующие нормы: поиск кандидата - 20 минут (включая перенос его резюме во внутреннюю базу данных) 10 минут - на прозвонку и приглашение на собеседование (для упрощения будем считать, что собеседуют кандидата другие менеджеры). Менеджер имеет право на один обед продолжительностью в час и два перерыва по 30 минут. Итого, менеджер за день должен найти минимум 14 кандидатов. Соответственно, у данной категории менеджеров, в рабочее время (с 9 до 18 часов), должен быть обеспечен бесперебойный доступ в Интернет (исключая плавающее время обеда и перерывов), бесперебойный режим работы компьютеров (аналогично), и бесперебойный доступ к местной телефонной связи. Для упрощения также предположим, что менеджер не приступает к поиску следующего кандидата, пока не «отработал» текущего. Таким образом, для менеджера по подбору можно выделить, как минимум, следующие сервисы со следующим SLA:

• Доступ в Интернет - с 9 до 18, с временем простоя не более 10 минут (в это время он может разговаривать по телефону с потенциальным соискателем).;
• Работоспособность ПК - с 9 до 18, с временем простоя не более 30 минут (в случае наступления времени простоя менеджер может сделать себе перерыв или пойти на обед);
• Доступ к внешней телефонной связи - с 9 до 18 с временем простоя не более 20 минут (в это время менеджер может производить поиск кандидата);
• Доступ к внутренней телефонной связи - с 9 до 18 с временем простоя не более 4 часов (внутренняя связь при описанной системе для менеджера нужна как вспомогательная функция, следовательно, ей назначено самое высокое время простоя);

В то же время, для координатора менеджеров (работает с 9 до 18, перерывы - те же, что и у менеджеров, задача - определение компетенций менеджеров, размещение заказов на кандидатов и категоризация кандидатов, решение текущих вопросов с менеджерами), который не занимается напрямую работой с клиентами, а работающего с внутренней базой, могут быть, например, выделены следующие сервисы со следующими SLA:

• Доступ в Интернет - с 9 до 18, с временем простоя не более 2 часов (Интернет ему не нужен для решения производственных задач, но, поскольку он занимает руководящий пост, то время восстановления работоспособности вспомогательного сервиса у него выше, чем у рядового менеджера);
• Работоспособность ПК - с 9 до 18, с временем простоя не более 30 минут (во время простоя координатор может сделать перерыв или пойти на обед);
• Доступ к внешней телефонной связи - с 9 до 18 с временем простоя не более 1 часа (работоспособность вспомогательного сервиса у него должна быть восстановлена быстрее, чем у рядового сотрудника);
• Доступ к внутренней телефонной связи - с 9 до 18 с временем простоя не более 10 минут (этот сервис для этого сотрудника является важным, поскольку требуется оперативный обзвон менеджеров для решения производственных вопросов);

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

Вторая парадигма ITIL - процессный подход и принцип «одного окна». C точки зрения ITIL, все, что происходит внутри отдела информационных технологий (вне зависимости от его размера), можно описать в рамках тех или иных процессов. В частности, ITIL (второй версии) выделяет следующие основные процессы:

В настоящее время официально опубликована библиотека ITIL версии 3, однако до сих пор не выполнено ее перевода на русский язык, поэтому перечень процессов приводится по ITIL версии 2. Подробнее об ITIL можно прочитать на официальном сайте ITIL: http://www.itil-officialsite.com/, сайтах http://www.itil.org.uk/ и http://en.wikipedia.org/wiki/ITIL

1. Управление инцидентами (скорейшее разрешение сбойных ситуаций, или инцидентов, представляющих собой отклонения от режима нормального функционирования сервиса)
2. Управление проблемами (предотвращение возникновения инцидентов)
3. Управление конфигурациями (хранение описания инфраструктуры и связи между ее элементами)
4. Управление изменениями (реализация изменений максимально безопасным образом)
5. Управление релизами (сохранение работоспособности инфраструктуры при проведении изменений)
6. Управление уровнем сервиса (определение параметров сервиса для конечного потребителя)
7. Управление финансами (обеспечение финансирования и бюджетирования ИТ)
8. Управление мощностью (обеспечение необходимых вычислительных мощностей для поддержки сервисов)
9. Управление непрерывностью (обеспечения непрерывности предоставления ИТ услуг)
10. Управление доступностью (обеспечение доступности сервисов, катастрофоустойчивость)

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

Итоги

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

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