ALEG: Сопровождение КИС

[Blog bot]

Источник: http://gotsdanker.spaces.live.com/Bl...8906!113.entry
==============
Опубликовано тут https://msdb.ru/Downloads/dynamics/v...e_dynamics.pdf

 

Сопровождение КИС: кому это под силу?

 
А. Готсданкер, Microsoft
 
Оптимизация затрат на сопровождение ERP-системы, снижение риска её отказа, уменьшение количества инцидентов, повышение удовлетворенности пользователей -- вот далеко не полный перечень задач, стоящих перед ИТ-службой.
Все вопросы сопровождения ERP-системы, затронутые в данном обзоре, не являются чем-то специфичным, скорее наоборот, можно сказать, что они тесно связаны с общими вопросами бизнеса и поддержки бизнес-функций. Но и для того, чтобы назвать направления деятельности ИТ-службы, ничего изобретать не надо, поскольку ориентир уже давно известен -- это совокупная стоимость владения, или TCO (Total Cost of Ownership). А в конце статьи будет рассмотрен еще один параметр – «удовлетворенность». Таким образом, все перечисленные выше задачи мы объединили в одну – снижение TCO, дополнив её удовлетворенностью пользователей.
Стоимость владения и пути её снижения

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

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

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

• Исправление ошибок:
  • Ошибки с приоритетом 1 исправляются в срок х,
  • ошибки с приоритетом 2 исправляются в срок y,
  • ошибки с приоритетом 3 исправляются одновременно с установкой очередного пакета обновления,
  • критические заявки на изменения существующей реализации в системе приравниваются к ошибкам с приоритетом 1

(прочие заявки на изменение реализации не входят в состав работ по сопровождению).
·        Поддержка законодательных требований осуществляется в срок до х дней после вступления в силу.
·        Уровень производительности обеспечивается в соответствии с результатами тестирования с допустимым отклонением ±10%.
·         Поддержка пользователей осуществляется с 9-00 до 18-00 пять дней в неделю:
o       реакция на запрос пользователя категории 1 составляет n минут,
o       реакция на запрос пользователя категории 2 -- h часов.
Список этот довольно приблизительный, хотя и построен на реальном опыте. Особо нужно отметить, что обеспечить предоставление указанного выше сервиса в определенных объемах невозможно без наличия так называемых резервных ресурсов. Таким образом, при переходе работы ИТ-службы на оказание определенного объема сервиса (SLA – соглашение об уровне сервиса) необходимо обеспечить резервные ресурсы, и наиболее распространенное решение в данном случае -- это использование внешних ресурсов (аутсорсинг).
Использование внешних ресурсов

При выполнении приведённого выше состава работ в указанных объемах вполне может возникнуть ситуация, когда для соблюдения SLA нужно привлечь дополнительные ресурсы. Но держать резервные ресурсы у себя не всегда бывает целесообразно. Службы, обеспечивающие деятельность непрофильных активов, как и сами эти активы, в целях уменьшения затрат могут быть переданы в совместное использование. На самом деле можно считать, что с ИТ-службой в какой-то мере это уже произошло, так как она обеспечивает работу всех бизнес-подразделений компании и очень редко одно бизнес-подразделение имеет в своем распоряжении выделенную ИТ-службу. Было бы вполне логично в данном вопросе продвинуться дальше и использовать одну ИТ-службу для обеспечения деятельности нескольких компаний.  Приведенём несколько вариантов использования внешних ресурсов для сопровождения ERP-системы.
1.      Сопровождение системы полностью передаётся на аутсорсинг. В данном случае руководитель ИТ-службы является ответственным за сопровождение, но вся необходимая работа выполнятся внешней компанией на основании соглашения об уровне сервиса. Внешняя компания в свою очередь самостоятельно формирует организационную структуру, рабочие процедуры и обеспечивает качество работ.
2.      Сопровождение системы осуществляется совместно с внешней компанией, и существует процедура передачи ей некоторой части заявок. Как правило, в данном случае имеется в виду многоуровневый подход к сопровождению. Распределение заявок между собственным ИТ-отделом и внешней компанией может осуществляться как по уровню сложности, так и по составу работ. (Например, администрирование системы ведётся собственными ресурсами, а исправление ошибок -- внешней компанией.)
3.      Сопровождение системы осуществляется полностью собственными силами и при необходимости, т. е. в критических ситуациях, внешней компании передается некоторый объем работ.
Любой из приведенных вариантов имеет право на существование, и основные критерии выбора в данном случае – насколько критично для бизнеса обеспечение работоспособности системы и каково соотношение качество/стоимость услуг внешних компаний.
Подход к сопровождению

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

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

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




==============
Источник: http://gotsdanker.spaces.live.com/Bl...8906!113.entry