Управление ИТ и тп. Современные технологии делопроизводства и документооборота
 Скачать 1 Mb.
|
Что теперь и куда дальше?"Создать единую точку доступа - хорошая мысль, но ведь человека выделить придется. А потом еще под каждый процесс - отдельного? А где отдача? И как собственно процессы внедрять?" Трудно однозначно сказать, приведет ли применение ITIL к увеличению потребности в ресурсах (в том числе кадровых) или нет. Это зависит как от уровня зрелости ИТ-отдела до начала внедрения (если он низок, то оптимизация работ может даже привести к их высвобождению) так и от "глубины" внедрения. Но даже если дополнительные ресурсы на каком-то этапе потребуются, не надо забывать о повышении общего качества работы ИТ. Это именно тот козырь, с помощью которого можно "выбивать" деньги у руководства. К сожалению, пока не измеряется качество услуг или хотя бы удовлетворенность пользователей (а это нереально без Центра Обслуживания), цифр и фактов для аргументации нет. Поэтому на этапе создания Центра Обслуживания придется либо обойтись внутреними ресурсами (могли появиться в процессе оптимизации операционного уровня) либо разработать и представить руководству план по реструктуризации отдела (например, берем дополнительного - дешевого - человека на ЦО, оптимизируем работу, через девять месвцев одного из двоих сисадминов сокращаем). Но в любом случае нужен среднесрочный (примерно на год-полтора) план внедрения. "Кадры решают все". Продумывав план "ITIL-изации" отдела надо в первую очередь оценить, кто из сотрудников более склонен к аналитической работе, кого можно "допускать до пользователей", а кому вы можете доверить работу, требующую максимальной педантичности. При этом надо ориентироваться не столько на профессиональные навыки сколько на человеческие качества. Исходя именно из этой оценки выбирайте владельцев процессов. Они будут вместе с вами "выстраивать" процессы, а потом контролировать и улучшать их работу. В выполнение конкретных процедур будут вовлечены и другие сотрудники (в том числе и владельцы других процессов), но отвечать должен он один. При этом ничто не мешает при распределении ответственности и полномочий совмещать разные функции и роли в одной должностной инструкции. Один и тот же сотрудник может быть владельцем одного или нескольких процессов и исполнителем - в других. Даже в отделе из двух человек в принципе возможно "поделить" между собой базовые процессы ITIL - причем с реальной пользой для дела. Если же ИТ-отдел состоит хотя бы из четырех человек распределение ответственности за процессы пройдет как по маслу. Для того, чтобы все эти управленческие телодвижения приносили удовлетворение вам и были оценены руководством, нужны "быстрые победы". На этапе оптимизации операционного уровня это регламентация плановых работ (а соответственно повышение их "прозрачности" и четкое планирование). В результате ИТ-менеджеру уже не будут сниться кошмары на тему "А что если PDC ляжет?!" - теперь у него есть регламентный бэкап, процедура восстановления и ответственный сотрудник. В создании Центра Обслуживания главная выгода - появление точки сбора информации обо всех событиях, происходящих в ИТ. Как результат через два - три месяца вы будете иметь статистику по обращениям пользователей, с которой уже можно идти к руководству с предложением о путях снижения их количества. Это уже те самые "цифры и факты", которые помогают ИТ в разговоре с Бизнесом. С этого и начинается выстраивание отношений "Поставщик - Заказчик". Кажется, теперь можно было бы и о внедрении процессов поговорить. Но если до сих пор рассказывать об ITIL можно было на "кухонном" уровне, тут уже требуется строгость определений и формулировок, знание терминологии и т.д. Поэтому настал момент погулять по Сети, а лучше всего сразу заказать книги Библиотеки. Не забывайте также о ценности вербального общения - курсы и семинары бесценный источник знаний. Успехов в ITIL-изации! Процессы.Определения."Раз ИТИЛ - процессный подход, надо наверно четко описать, а лучше определить - что же такое процесс?" Можно, конечно, заглянуть в толковый словарь и прочесть там что-то вроде: последовательная смена состояний, каких-л. явлений, ход развития чего-л.; совокупность последовательных действий для достижения какого-л. результата, напр. производственный п. Это в общем то и так "интуитивно ясно". Однако из п.2 мы видим, что помимо "процессов вообще" есть например производственный процесс, так что надо идти глубже, чтобы понять специфику именно ИТИЛовских процессов и получить "рабочее" определение. В нем, во-первых, должно быть собрано специфичное для ИТИЛ содержание (в частности, нацеленность на услуги и качество) и во-вторых, дано внутренее строение и внешние связи. Итак, начнем изыскания. Наиболее общее определение дает нам ГОСТ Р ИСО 9000 - 2001: "Процесс - совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы. В ITIL - точнее в книге "Service support" ("Поддержка услуг") приводится следующее определение: "A connected series of actions, activities, Changes etc. performed by agents with the intent of satisfying a purpose or achieving a goal." ("Связанный набор действий, видов деятельности, изменений и т.д., выполняемый агентами с целью удовлетворения потребности или достижения цели.") Здесь добавилась важная для понимания процессов составляющая - агенты. Кроме того, вместо выходов (про которые забывать не надо, поскольку при проектировании процесса их придется выделять и специфицировать) упомянуто, что у процесса есть некая цель. Вот еще одно (CobiT): "Процесс - это действие, направленное на достижение результата, которое может корректироваться при его выполнении и которое сосредоточенно на достижении конечного результата при оптимальном использовании ресурсов." Отсюда мы можем взять две вещи: процесс должен управляться (корректироваться) и его надо строить оптимально. Можно наверно найте полезные зерна и в других источниках, но большинство так или иначе повторяют уже сказанное. Например в PMBOK 2000 edition читаем: "series of actions bringing about a result". Так что перейдем к тому, из чего он состоит. Предлагается такое деление процесса на составляющие: подпроцесс (subprocess) - является частью процесса, но не теряет его свойств деятельность (activity) - набор действий выполняемых одной ролью действие (action) - атомарная единица процесса Кроме того, надо не забыть о том, что процессы надо как-то описывать. Для этого существует процедура - описание логически связанных деятельностей и их исполнителей (для большей детализации и удобства обычно составляют набор Рабочих инструкций, которые определяют, как следует выполнять виды работ, входящие в состав процедур). И, наконец, помимо ролей для каждого процесса важно определить владельца (именно он отвечает за него, имеет право его менять и т.д.) и менеджера (он осуществляет "оперативное управление"). Конечно это тоже роли, но роли специфические и очень важные. Они должны быть четко определены для каждого процесса, даже если выполнять их будет один человек. Постараемся теперь ничего не потерять но и без лишнего обойтись: Процесс - это цикличный и воспроизводимый набор логически связанных деятельностей, направленных на достижение общих целей, описанных процедурами и исполняемых менеджером процесса и другими ролями (агентами) с использованием выделенных ресурсов, управляемый владельцем для оптимизации по затратам с использованием измеряемых характеристик (метрик), который преобразует определенные входы в контролируемые по качеству выходы. (Process - a cyclic and reproduced set of logicaly related activities connected by general targets, described by procedures and performed by process manager and other roles (agents) using allocated resources, controlled by the owner to be optimal in efforts and costs using measured indicators (metrics), which convert specified inputs into the quality controlled outputs.) Возможно, результат получился громоздким, но зато теперь мы знаем, что такое процесс "по-ИТИЛовски". Методика внедрения процессов."Определение внушительное. Только из него все равно не ясно, как процессы эти создавать, в смысле выстраивать." Попробуем кратко прикинуть, в каком порядке и что именно надо делать, чтобы "построить" ИТИЛовский процесс. Итак: Вначале необходимо для процесса определить цели (с ключевыми факторами успеха для первой стадии), входы-выходы, ресурсы, политики. Затем составить список процедур (для них - входы-выходы, цель, контроль) Далее - шаблоны информационных ресурсов (к примеру - что должно быть в любом trouble ticket), первая версия справочников (к примеру - типы service call, статусы инцедентов, etc). Наконец - подробное (пусть черновое, но чтоб по ним работать можно) описание процедур и базовое описание ролей. Все, можно "вводить в эксплуатацию" и заниматься: корректировкой написанного уточнением процедур и ролей написанием рабочих инструкций. Последовательность внедрения ITIL-процессов."Отлично, можно приступать. Начинать наверно надо с Процесса Управления Услугами - он ведь ключевой." Действительно Управление Услугами - в своем роде "центральное звено" для всех ИТИЛовских процессов. В создающейся "с нуля" организации или подразделении начинать именно с него может быть правильно. Но для уже функционирующей структуры это не лучший путь. Перед тем, как ответить себе на вопрос "за какой процесс браться в первую очередь", надо понять "что имеем", то есть оценить степень зрелости как всего ИТ в целом, так и групп процессов управления ИТ. Конечно, для оценки группы процессов придется рассматривать каждый, но для того, чтобы решить, с какого процесса начинать, нужна интегральная оценка зрелости групп. Методик оценки зрелости существует немало и здесь не место обсуждать их и сравнивать. Предположим, что выбрана некая методика, проведена оценка и на выходе у нас для каждого процесса - балл от 0 до 5. Теперь надо рассмотреть оценки по группам (Operational, Support, Delivery). Если в группе Операционных процессов есть хоть один с баллом ниже тройки - забудьте временно про "отношения Бизнеса и ИТ" и прочие высокие слова - подготовьте себе тылы (в данном контексте под Операционными процессами имеется ввиду все то, что называют Technical, Operations, а также Environmenal Management). Однако не надо забывать о следующей цели - уровне Поддержки Услуг. На нем есть бесценная функция - Центр Обслуживания, которая может помочь и на этапе приведения в порядок операционного уровня. Итак, первый шаг при таком раскладе - создание Центра Обслуживания и ""доведение до ума группы операционных процессов (внутри нее - Technical => Operations => Environmenal, подробнее - зависит от используемых технологий). Говоря о группе процессов Поддержки Услуг, можно предложить такой порядок: сперва Управление Инцидентами и Проблемами (вместе с "причесыванием" Центра Обслуживания), затем Изменения, потом Конфигурации и Релизы. Опять же надо помнить о следующей цели - Доставке Услуг - и параллельно с процессами уровня Поддержки хотя бы контурно обозначить рамки и содержание Процесса Управления Услугами. Заработав минимум по три балла процессам поддержки, можно довести до ума Управление Услугами и ... сделать шаг в сторону от доставки услуг, задумавшись над тем откуда они (услуги) берутся. Конечно если в вашей организации набор сервисов крайне стабилен и с его изменением вполне справляется операционный уровень - можете не волноваться. Если же время от времени присутствует некий development - самое время заняться именно им. Так что следующий шаг - Production Management. Если вы добрались до этой стадии - наверно сами разберетесь, в каком порядке внедрять Availability, Capacity и Continuity Management. А Управление Финансами советую оставить "на сладкое" - с него плавно перейдете на Business - IT alignment, займете место CIO... Все вышесказанное относится в первую очередь к тем ИТ-структурам, в которых идея жить по-ИТИЛовски идет "изнутри". Если же к вам "сверху" пришло указание <<внедрить SLA за три месяца>> - деваться некуда, порядок внедрения будет совсем другой. Кроме того, это только общие принципы, описывать же порядок для всех вариантов результата оценки зрелости - за отдельные деньги. А тонкостей может всплыть немало. Например, если процесс Service Continuity Management получил ноль баллов - бросьте все и готовьтесь к пожару-наводнению-землетрясению. Так что изучайте внимательно best practice. И не забывайте - ITIL <=> IMHO :-) Как оценивать ИТ-активы?Существующие методы оценки ИТ-активов являются сугубо субъективными. Результаты, полученные разными аудиторами, могут отличаться в 2-3 раза, в итоге сама оценка теряет смысл. Тем не менее, оценивать ИТ-активы нужно и можно. Главное – применить правильный подход. Кому и зачем нужна оценка ИТ?Российский ИТ-рынок, уже измеряется весьма серьезными цифрами, и продолжает расти дальше, что делает актуальной задачу стоимостной оценки этих самых "ИТ". Причем, помимо личного, инициативного желания самих собственников ИТ-активов узнать, сколько стоит то, чем они владеют, существует еще и достаточно большое количество случаев, когда такая оценка должна проводиться в обязательном порядке. Например, она обязательна при внесении ИТ-активов в уставный капитал юридических лиц, при их постановке на бухгалтерский учет (в качестве нематериальных активов), при уступке прав на них, при передаче прав на их использование на лицензионной основе, при приватизации и ликвидации предприятий, имеющих эти объекты на балансе, и при их залоге. А самое главное - она неизбежна как часть ежегодного общего аудита, обязательного для всех открытых акционерных обществ, кредитных организаций, страховых компаний и обществ взаимного страхования, товарных и фондовых бирж, инвестиционных фондов, государственных внебюджетных фондов, и всех других организаций, в случае, если объем их выручки от реализации продукции (товаров, услуг) за год превышает 500 тысяч МРОТ (около 50 млн. рублей), либо если итог актива их баланса на конец года составляет более 200 тысяч МРОТ (около 20 млн. рублей). Другими словами, оценка ИТ-активов актуальна если не для всех компаний вообще, то для очень многих из них. Так как же и чем их "мерить?" Методик и стандартов хватаетПри "индустриальном" подходе задача стоимостной оценки решается предельно просто, - путем применения известных и отработанных технологий и методик, - "затратных", "доходных", "рыночных". При "затратных" происходит установление фактических расходов на создание, приобретение и введение ИТ-объекта в хозяйственный оборот, приведение разновременных затрат предыдущих периодов к текущей стоимости (на дату оценки), в соответствии со специальными коэффициентами перерасчета, индексом цен и уровнем инфляции, ставками банковских процентов по вкладам и кредитам, и определение суммы амортизационных отчислений по этим ИТ-объектам. При "рыночных" - расчеты осуществляются с помощью методов сравнительных (сопоставимых) продаж, экспертных оценок, и сопоставимых роялти. При этом оценка производится на основе сходства оцениваемого объекта с аналогичными объектами в условиях "эффективно функционирующего" рынка и осуществляется путем сравнительного анализа конкретных технико-экономических параметров сходных объектов. Для проведения таких расчетов необходима информация о других состоявшихся сделках по аналогичным объектам, перечень сравниваемых параметров/показателей этих объектов и результаты корректировки фактических цен по сделкам. При "доходных" методиках, - определяется обобщенная выгода от обладания этим ИТ-объектом. Рассчитывается увеличение приходящего дохода (за счет возрастания цены/ количества выпускаемой продукции/услуг), рассчитывается уменьшение расхода (за счет снижения себестоимости, уменьшения потерь, освобождения от альтернативных расходов), и рассчитывается изменение баланса доходов и расходов. Для этого рассчитываются затратные факторы формирования цены, виды доходов и доли по каналам денежных поступлений, объемы производства, прогнозы доходов и расходов приводятся к текущей стоимости и т.д. и т.п. Все эти методы и способы уже давно и хорошо известны. Поэтому для оценки любого ИТ-объекта (изделия/технологии/услуги…) надо просто приглашать сертифицированного и лицензированного оценщика и финансировать его функционирование. Для верности (и солидности) можно одновременно пригласить нескольких независимых оценщиков - тогда результат их труда будет еще более убедителен и обоснован. Главная тайна аудиторовВсе написанное выше - правда, и на этом, тему оценки можно было бы считать исчерпанной, если бы не одно существенное обстоятельство. Дело в том, что результаты различных оценок одних и тех же ИТ-активов могут различаться не на проценты, и даже не на десятки процентов. Они могут различаться в разы, а то и на порядок. Какой же из полученных результатов будет верным, а какой - нет? Они все будут верными, просто каждый будет верен по-своему. Встает вопрос, из-за чего стоимостные оценки одной и той же ИТ-сущности могут так сильно различаться ? Для понимания этого неожиданного факта нужно набраться терпения и внимательно углубиться в весьма объемные методики финансовых расчетов, плотно нафаршированные многочисленными формулами. Эти формулы, у лиц, не обремененных математической подготовкой, наверняка вызовут трепетное уважение, но для ИТ-специалистов они –окажутся очень интересны и весьма поучительны. Вот например, святая-святых всех без исключения методик, "Расчет стоимости объектов промышленной собственности в целях принятия на баланс предприятия в качестве учетной единицы в состав нематериальных активов и отражения в бухгалтерском учете". Это - начало "системы координат", "точка отсчета", "ноль" всех без исключения последующих вычислений и расчетов. Обобщенно, и упрощенно, расчетная формула имеет вид: С = к х В, где "В" - это достаточно объемная арифметическая конструкция, из большого количества величин и параметров. Особый интерес представляет параметр "к", который представляет собой "коэффициент морального износа объекта промышленной собственности на дату оценки" и "… определяется экспертно …". Причем коэффициент может принимать значения от 0 до 1. В переводе с бухгалтерского языка на обычный это означает, что один "эксперт" может выставить оценку "0,3", а другой - "0,6", и результирующие величины двух оценок, при одном и том же "В", будут различаться в два раза. При этом оба эксперта могут быть вполне вменяемыми действовать абсолютно искренне. Изучаем методики дальше. Центральное "ядро" всех "доходных" методик - оценка "объектов промышленной собственности с целью определения дохода правообладателя". Главная формула - "расчет чистой прибыли, полученной экономическим агентом в результате использования объекта". Тоже внушающая уважение конструкция, в которой также имеется некая загадочная величина. Описывается она так: "Размер будущих денежных потоков, которые будут получены от использования объекта промышленной собственности". Но как их определять, эти "будущие потоки?" Ведь для этого нужно иметь абсолютно полную информацию о том, что будет в будущем, причем - не только на данном рынке, но и во всей экономике, так как все рынки взаимосвязаны. Что важно, оценка требуется не качественная, а количественная – необходимы конкретные цифры. Причем цифры - не на месяц - два, а на несколько лет вперед. Такая же ситуация с величиной "дополнительной стоимости единицы продукции, товара (работ, услуг), произведенных с использованием объекта промышленной собственности". Как вычленить именно ту долю дополнительной стоимости, которая будет получена именно за счет использования рассматриваемого ИТ-объекта? Например, если в бухгалтерии хлебокомбината будет внедрена бухгалтерская ИТ-система - на сколько объективно увеличится стоимость батона хлеба, идущего в розничную продажу? Как определяется эта величина? Опять "экспертная" оценка. И т.д. и т.п. И это - без рассмотрения многочисленных и разнообразных "коэффициентов дисконтирования", встречающихся практически в каждой формуле, и "приведение будущих расходов/доходов к текущему периоду", что попросту невозможно без знания обменных курсов валют на много лет вперед. Примечательно, что во всех подобных расчетах используется сразу несколько величин, определяемых экспертно, так что их "люфт" мультиплицируется, и результирующий разброс получающихся значений делает сами расчеты просто бессмысленными. Потому что, если некая численная величина может быть вычислена с погрешностью +/- 5-10%, ее еще можно принять, но если погрешность вычисления составляет уже 70-80%, а то и все 200-300%, - то зачем она вообще нужна? Попутно можно отметить, что во всех стандартах, методах и методиках делается четкое и однозначное разделение "нематериальных активов", "интеллектуальной собственности" и "результатов научно-технической деятельности", что для ИТ бессмысленно, ибо они прекрасно подходят под любую из этих категорий. За рубежом не лучшеНо это все были российские методики, взятые из "Методических рекомендаций по определению рыночной стоимости интеллектуальной собственности", "Порядка инвентаризации и стоимостной оценки прав на результаты научно-технической деятельности", стандарта РОО СТО РОО 26-01-96 "Оценка нематериальных активов" и РОО СТО РОО 26-02-98 "Оценка объектов интеллектуальной собственности". Может, на международном уровне все эти вопросы уже давно и успешно решены? Основополагающими стандартами по данному вопросу являются: "Международные Стандарты Оценки" (МСО-2001), "Европейские Стандарты Оценки" (ЕСО-2000, European Valuation Standards 2000), и "Международные Стандарты Финансовой Отчетности" (МСФО-38 «Нематериальные активы»). А кроме того, существует огромное количество других методик и рекомендаций расчета абсолютно любых экономических показателей, при абсолютно любых условиях, для абсолютно любых целей. Рассмотрим методики расчета показателей возврата инвестиций ROI (return on investment), срока окупаемости РР (Payback period), простой нормы прибыли SRR (Simple rate of return), чистой текущей стоимости NPV (net present value), индекса прибыльности PI (Profitability index)… Везде, в каждой формуле обнаруживаются "старых знакомые" – величины, определяемые экспертно. Причем ключевым словом во всех комментариях и примерах к этим многочисленным методикам стоит слово "предположим". Но ведь предположить можно что угодно! Кроме того, механический перенос на ИТ методов и методик, разработанных для материального, а то и вообще - чисто финансового инвестирования, в подавляющем количестве случаев приводит к просто бессмысленным результатам. Для ИТ не существует "физического" износа (ибо он равен "0"), и соответственно - амортизации, но в тоже "остаточная стоимость", понимаемая в значении возможности реализации данного б/у актива на рынке, всегда и везде равна "0". Так же для ИТ-объектов не существует "экземплярной" себестоимости (и 5, и 10, и 100 копий программы стоят столько же, сколько и 1 (стоимость носителя к стоимости самой программы никакого отношения не имеет). Что же касается принимаемого за аксиому однозначного разделения процесса создания ИТ-решений на "исследования" и "разработку", то оно в корне неверно. И самое главное: для расчета экономических параметров всей схемы нужно всегда идентифицировать численный "выход" ИТ-технологий, их "долевой" вклад в увеличение/уменьшение стоимости/количества выпускаемой продукции или услуг. А по поводу этой "доли" - не ясно не только то, как ее "считать", но и даже то, какой формат она должна иметь. В этих условиях любые численные расчеты "экономики" ИТ-технологий, совершаемые по методикам, разработанным для материальных или финансовых активов, представляют собой не что иное, как закамуфлированное мошенничество, прикрытое и оправдываемое благими (или не очень) намерениями. |