?

Log in

No account? Create an account
Хроника затяжного прыжка [entries|archive|friends|userinfo]
maxtar

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Из чего состоит ITIL, основополагающие принципы [Jan. 27th, 2010|02:29 pm]
maxtar
[Tags|, ]

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

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

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

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

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

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

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


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

Выглядит процесс примерно так:


При описании процесса четко указывается:
1. Вход ("с чего начинается") и выход ("что должно получиться") процесса.
2. Цель процесса, т.е. для чего он существует в терминах бизнеса.
3. Специальные роли: владелец и менеджер процесса (в ITIL v3 эта роль больше не упоминается).
4. Этапы выполнения процесса.
5. Матрица ответственности по каждому из этапов (ответственный/исполнитель/участник-информатор/информируемый).
6. Метрики процесса (те самые измеримые величины, которые дают возможность оценки его производительности).

Вам ничего не напоминает приведенная выше картинка? А ведь это - АЛГОРИТМ. Только операторами и переменными в нем являются ЛЮДИ, которые получая определенную информацию или реагируя на какое-то событие - должны выполнить какие-то действия для достижения ранее определенной цели! Кроме того - деятельность, описанная подобным образом, можно легко и с минимумом ошибок автоматизировать. Вот возможность "программирования действий людей" и легкость автоматизации (благодаря чему эффективность работы сотрудников грандиозно возрастает) меня больше всего и прельщает в процессном подходе.

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

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

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

Ответ в известном афоризме Карнеги: "Лично я предпочитаю клубнику со сливками, но на рыбалку беру червей, потому что рыба любит именно их, а не клубнику со сливками!". Хотя более подходящим к обсуждаемой теме является процитированное в самом ITIL высказывание профессора Левита из HBS - "Люди не хотят четверть-дюймовых сверл! Им нужны четверть-бюймовые отверстия!"


Так и бизнесу привычнее всего иметь дело с покупкой-продажей товаров или услуг. Вся суть ITSM можно представить просто как "представление всей деятельности ИТ-службы в качестве услуги". Что при этом считается услугой - является предметом договоренности между ИТ и бизнесом, но в идеале ИТ должен предоставлять только услуги, несущие конечную и ощутимую ценность. Например несут ли собственную ценность для бизнеса такие вещи, как электронная почта, антивирусная защита, доступ в интернет или пакет MS Office? Крайне сомнительно. Ибо сами по-себе вышеперечисленные вещи работать не могут. Поэтому логично представить вышеперечисленное как входящие в услугу под названием (например) "Стандартное рабочее место".

Потом подсчитать расходы на всё, что подразумевается под "Стандартным рабочим местом", его амортизацию (ведь прийдется его менять со временем), лицензии, сопровождение железа и ПО, поддержку сети и канала доступа в интернет и выставить счет бизнесу. В идеале - в виде только ежемесячных платежей, без всяких "плат за подключение". Получившееся в результате - идеально ложится в текст обычного договора (который в случае ITSM называет SLA - Service Level Agreement).

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

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

ITIL это, как известно - IT Infrastructure Library, т.е. библиотека. И состоит, как ни удивительно - из книг. :) В ITIL v3 таких книг наблюдается всего 5:
Service Operation
Service Transition
Service Design
Service Strategy
Continual Service Improvement

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

Просьба оживленно комментировать и публиковать ссылки на запись. А то мне надоест. :)

Мои заметки на тему ITIL:
(Предпоссылки возникновения ITIL)
(История, суть и место ITIL среди IT-стандартов)
(Из чего состоит ITIL, основополагающие принципы)
(Процессы ITIL и их связи)
(Обучение и перспективы ITIL)
Link20 comments|Leave a comment

navigation
[ viewing | most recent entries ]