5 шагов к успеху постпроектного сопровождения. Опыт партнеров 1С

Меня зовут Владимир Павлов, я руковожу направлением корпоративного сопровождения в фирме «1С».

Для айтишника я уже сильно пожилой человек – у меня уже есть пенсионное удостоверение. В области ИТ я работаю уже более 40 лет – в отличие от многих других инженеров, в то время айтишники не бросали свою занятость в связи с определенными событиями, происходящими в стране.

Я достаточно долго был программистом и потом, естественно, руководителем проектов. Руководил различными подразделениями – как в крупных компаниях, так и в партнерской сети. И потом пришел к выводу, что уже долго и упорно занимаюсь сопровождением – фактически сервисным подходом.

Имею соответствующую сертификацию – ITIL Expert и Service Manager ITIL. В том числе, конечно, сертификацию PM IPMA D как руководитель проектов.

Немного мудрости:

• Конечно, корпоративные системы – это всегда продолжительные проекты.

• Но, как известно: «Всем нашим встречам разлуки, увы, суждены» – рано или поздно проекты заканчиваются. И после проектов тоже должна быть жизнь.

• Причем проекты – это всегда экстремальное занятие. Поэтому, естественно, люди сплачиваются, но, тем не менее, они расходятся. И в этой ситуации очень важно расстаться в ситуации «не навреди». Я это сформулировал таким образом: «Уходя-уходи, но помни, что твой уход может повлиять на лояльность заказчика к тем, кто остается». Поэтому сопровождение – это регулярный процесс и долгосрочное сотрудничество. Это очень важно иметь в виду.

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

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

Немного теории

Информация в моем докладе опирается на стандарт ISO 9000-2015 по системе менеджмента качества. Это не сервисный подход ISO 20000, не PMBoK или еще что-то, это конкретные основы. Согласно этим основам:

• Проект – это уникальное мероприятие, уникальный процесс.

• Он охватывает несколько различных видов деятельности, в нем задействованы разные специалисты. Например, когда мы внедряем систему: кто-то разрабатывает требования и пишет ТЗ; кто-то реализует, программирует; кто-то создает инфраструктуру.

• Правильный проект должен соответствовать конкретным требованиям, в противном случае мы сталкиваемся с рисками. Причем мы должны определить не только технические требования, но и бизнес-требования – требования бизнеса должны быть конкретными.

• В проекте всегда есть начальная и конечная дата – если их нет, это неправильно.

• Есть цели – они описаны в требованиях, в том числе, бизнес-цели.

• И со всеми этими составляющими мы должны уложиться в классический проектный треугольник: сроки, стоимость, ресурсы.

Так выглядит проект – мы все к этому привыкли.

А что же такое сопровождение, куда мы должны перейти после проекта?

• Сопровождение – это результат процесса организации. И здесь никакой уникальности быть не должно, потому что уникальное сопровождение, как и любой уникальный сервис – это очень дорого. Типизация должна быть на уровне организации, а не на уровне уникальности проекта.

• Услуга сопровождения должна обладать по крайней мере одним действием, обязательно осуществленным при взаимодействии организации и потребителя.

• Здесь важно понимать: нет взаимодействия – нет услуги. Если в проекте мы часто замыкаемся во взаимодействии внутри команды, где участвуют и представители заказчика, и представители исполнителя, то здесь все по-другому – взаимодействие на первом месте.

• И услуга сопровождения часто охватывает деятельность регулярных процессов организации – сюда относятся повторяющиеся процессы высокой степени определенности.

Что же предлагает фирма «1С» в рамках методической поддержки?

• Первое, святое – это стандарт 1С:ИТС. Его обязаны соблюдать все партнеры, он серьезно проработан методически – на сайте its.1c.ru подробно описаны эти регулярные процессы.

• Для корпоративного сектора рынка у фирмы «1С» есть две технологии – Технология корпоративного внедрения и Технология корпоративного сопровождения.

• Есть готовые методики обучения и сертификация – как у любого вендора, у фирмы «1С» это сильно развито, и это тоже одна из основ, причем связанная со стандартом 1С:ИТС. Плюс, конечно же, есть курсы и по корпоративному внедрению и корпоративному сопровождению.

• И последнее – авторский надзор фирмы «1С». Это трехсторонний договор, когда вендор курирует серьезное корпоративное внедрение.

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

Теперь о проектах. Проекты завершаются – «Всем нашим встречам разлуки, увы, суждены».

Я выделил три сценария завершения проекта.

• Первый сценарий – это расставание. У него есть три варианта:

  • если нас не устраивают результаты, мы поскандалили, и все кончилось плохо – естественно, мы здесь не говорим о сопровождении;

  • или мы можем расстаться друзьями – но, скорее всего, сопровождения там тоже не будет;

  • и последнее – смена исполнителя проекта, как вы догадываетесь, сопровождение будет, но не теми, кто делал проект.

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

  • либо заказчики начинают эксплуатировать сами;

  • либо они привлекают каких-то других партнеров.

• И последнее – win-win. Когда мы успешно завершили проект и продолжаем сотрудничать с заказчиком, достигая новых результатов – идя к новым проектам и может быть целым проектным программам.

Различая варианты завершения проекта, мы понимаем, когда мы уверенно получаем сопровождение, и когда сопровождение под вопросом.

Когда начинаем сопровождение

Теперь по поводу экстремальности и адреналина.

Жизненный цикл проекта – это американские горки.

• Сначала проект совершает первый виток – мы создаем информационную систему.

• Потом происходит второй виток – начинается опытная эксплуатация. Это большое испытание и стресс для исполнителей, потому что они уже серьезно подустали, и тут вдруг вокруг появляется много людей, которые кидаются на проектную команду.

• И в конце линия проекта как-то выравнивается, переходя в прямую.

Находясь на втором витке, нам важно не испугаться, а начать запускать корпоративное сопровождение – для этого не нужно ждать конца проекта.

Но как нам прийти к тому, чтобы как можно раньше начать сопровождение, разгружая команду проекта? Правильнее всего продавать (и покупать) внедрение и сопровождение вместе.

Какая мотивация к этому? Продавая их вместе, мы:

• Обещаем эффективную эксплуатацию под лозунгом: «Мы всегда с вами. Мы знаем, что внедряли, и будем хорошо это сопровождать дальше».

• Гарантируем устойчивое развитие системы при необходимости ее модификации, потому что владеем всей информацией о внедренном решении.

• Управляем компетенциями пользователей и ИТ-персонала.

• И понимаем, как посчитать совокупную стоимость владения системы.

Все это нам дает гарантии инвестиций.

Пять шагов к успеху

А теперь пять шагов – как прийти к этим чудным результатам:

1. Взаимодействие с командой проекта. Это не самая простая задача. Например, вы приходите к руководителю проекта с проблемой, а он говорит: «Погоди, потом, послезавтра я может быть с тобой поговорю». Это первое и важное.

2. Проектная документация и создание базы знаний. Написанное в начале проекта ТЗ к моменту завершения проекта, мягко говоря, не всегда похоже на то, что в итоге сделано. Поэтому мы должны создать базу знаний или привести документацию в соответствие, чтобы ее в дальнейшем можно было использовать для развития системы.

3. Взаимодействие с заказчиком и требования к услугам. Пообщавшись с командой проекта, надо взглянуть на другую сторону – повзаимодействовать с заказчиком и понять требования к услугам.

4. Каталог услуг и заключение SLA. На основе требований к услугам нужно составить каталог услуг и заключить по нему SLA.

5. Процессы предоставления услуг, создание команды и инфраструктуры сопровождения. И если у нас еще не налажены регулярные процессы или их недостаточно, мы создаем необходимые процессы, создаем команду и инфраструктуру для сопровождения.

Разберем каждый шаг детально.

Первый шаг – взаимодействие с командой проекта.

У этого шага есть две цели:

• Оценить состав и текущее состояние объектов сопровождения. Под объектами сопровождения нужно понимать не только внедряемую нами систему, но и те объекты, которые будут с ней интегрироваться. Интеграция вообще свойственна для экосистемы 1С – например, 1С:ЗУП всегда трогательно связан с 1С:Бухгалтерией. Плюс у нас может быть интеграционная шина, 1С:Аналитика, или еще что-то. Это должно быть включено в контур.

• Вторая цель – обеспечить оптимальный переход от внедрения к эксплуатации. Эксплуатация – это то, ради чего делался проект. Сопровождение должно ее поддерживать – это важно.

Какие мероприятия мы должны провести?

• Принятие решения об организации сопровождении на управляющем комитете проекта. Мы должны заручиться поддержкой руководства. Без поддержки руководства руководитель проекта будет нас мягко избегать… и не всегда мягко.

• Совещание с руководителем проекта и ключевыми участниками команды проекта. Часто в начале проекта проводится стартовое совещание – это очень похоже.

• Планирование совместных работ и привлечение необходимых ресурсов.

• И самое главное – мы должны включиться в проект и участвовать во всех статус-совещаниях, которые проходят в ходе проекта. Чем раньше мы подключимся в совместные обсуждения, тем понятнее нам будет, с чем мы имеем дело.

И инструменты, используемые на этом шаге, понятны:

• какие-то системы управления проектами;

• 1С:Профкейс 3.0 и другие методические материалы 1С – читаем и записываем;

• и, если есть, – авторский надзор.

Второй шаг – проектная документация.

Здесь мы обязательно должны сделать важный документ – паспорт системы. Это наша главная цель. И на слайде я еще в кавычках поставил слово «аудит», хотя, конечно, никакой это не аудит. Вы просто берете документацию, которая была создана в ходе проекта на разных его фазах и этапах, и смотрите, насколько она соответствует тому, что есть.

Дальше перечислен состав документов – то, что написано в ТКВ. Если у вас все эти документы будут – замечательно. Понятно, что они у вас будут не всегда, но пункт № 6 паспорт системы – на этом надо настаивать. И конечно же, у нас должны быть задокументированы запросы на изменения, которые поступают в ходе проекта.

И последнее – инструменты.

• Сюда относится система электронного документооборота, всем известный Документооборот 1С:ДО. Сразу начинайте складывать туда проектные документы. Причем сделайте по ним цикл. Например, у вас есть документ «План проекта», сделайте для него статусы: запланирован, в работе, разработан проектной командой, принят командой сопровождения, утвержден заказчиком. Этот жизненный цикл сформирует нам документированную информацию о проекте в ходе его реализации. У многих партнеров такое есть.

• А дальше, уже анализируя эти документы, мы будем переносить их в базу знаний – либо целиком, либо частично, либо в виде инструкции, либо в виде программы обучения. Есть некоторые наработки партнеров по созданию базы знаний для ДО.

Третий шаг – определение требований к услугам.

После того как мы пообщались с командой проекта, приняли, что есть, мы начинаем общаться с заказчиком.

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

Кроме этого, нужно собрать и формализовать требования к услугам.

Четвертый шаг – разработка каталога услуг.

Каталог услуг – основа всего в сервисном подходе.

Я не люблю проекты сопровода и работу по заявкам, потому что они приводят к уникальности, а как следствие – к очень большим затратам. Мы пытаемся оказать такой лакшери-сервис. Хотите рояль? Давайте у нас будет в серверной стоять белый рояль. Не надо такого. Вам не нужен рояль, он дорогой и много места занимает – еще не дай Бог рассохнется от системы вентиляции.

Поэтому определяем услуги.

А дальше у нас есть инструменты:

• Система Service Desk.

• И конечно, если вы хотите сделать это быстро и хорошо, возьмите типовой каталог из 1С:ТКС. Кстати, в стандарте ИТС тоже есть каталог услуг.

И последний шаг – это организация процессов, инфраструктуры и всего того, что нужно для сопровождения.

Это длинный процесс. Не буду сильно на нем останавливаться. Но очень важно, что процессы должны быть регулярными и формализованными.

Важные аспекты для принятия ИС на сопровождение

Помимо пяти шагов, есть несколько важных аспектов.

Первый и главный – база знаний. Расскажу свое мнение, как она должна быть организована.

• Первое – охват базы знаний. Нам должно быть понятно, какие знания мы вносим в базу знаний. Должен быть понятен путь: от проектной документации, от некоторого опыта к структурированным знаниям, которые можно использовать при поддержке.

• Второй важный момент – это дерево знаний, куда включены традиционные разделы:

  • Глоссарий, который охватывает все – обязательно;

  • Информационные системы;

  • Предоставляемые услуги;

  • Часто задаваемые вопросы;

  • Очень важна обратная связь – комментарии и оценки от тех, кто использует знания. Из них формируются рейтинги статей.

• И последнее – организация знаний. Это некие алгоритмы, которые позволяют нам искать знания, использовать их и оценивать (в частности, алгоритмы расчета рейтинга статей).

Второй важный момент – передача ответственности при переходе на сопровождение.

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

В первом списке задачи:

• Изучить прогноз погоды;

• Подготовить машину;

• Закупить продукты;

• Взять одежду, игрушки;

• Дальше еще у бабушки задачи посадить рассаду, взять инструмент.

И колонки с ответственными, где проставлено:

• R (Responsible – ответственный за работу) – тот, кто непосредственно выполняет задание;

• A (Accountable – ответственный за результат) – тот, кто принимает работу и несет ответственность за результат;

• C (Consulted – консультирующий) – тот, кто оказывает консультативную помощь;

• I (Informed – информируемый) – тот, кто в курсе принимаемых решений и хода выполнения задачи.

Обратите внимание, что переезд на дачу – это проект, и область ответственности лежит в области папы и мамы.

А при сопровождении область ответственности перемещается к тем, кто использует дачу: это бабушка, сын и кот.

Логика этого слайда такова: при передаче системы на сопровождение осуществляется переход ответственности от тех, кто реализовывал проект, к тем, кто эксплуатирует систему. Помните про это. Может быть, матрица RACI вам пригодится – особенно в корпоративных проектах, где много всего.

Третий момент – паспорт проекта.

По поводу паспорта специально вставил на слайд много картинок и много умных слов, чтобы вы напугались и поняли, что паспорт системы – большой, важный и нужный документ. Его нужно делать.

Четвертый важный момент – риски.

Все понимают риски проекта, но не все хотят думать о рисках сопровождения.

Команда исполнителей завершила проект, выдохнула и забыла про риски навсегда. Но относительно заказчика риски никуда не ушли – они остались, но трансформировались. Из проектных рисков, где риск понимается как событие, которое с какой-то вероятностью случится или нет, мы переходим к рискам неопределенности.

А неопределенность возникает из-за того, что документация неактуальная.

На слайде перечень инициаторов рисков:

• Для руководителя проекта исполнителя все риски находятся в области завершения. Там самый главный риск: мы так здорово трудились, делали, а они не берут.

• Если мы посмотрим руководителя подразделения сопровождения, то для него главный риск – это недостаток или отсутствие различных видов ресурсов и знаний для эксплуатации и сопровождения.

Регулярно происходит трансформация управления рисками от рисков проектных к рискам операционным. Они немного другие, но они никуда не делись – как с точки зрения людей, кто в этом участвует на стороне заказчика, так и с точки зрения исполнителя.

Область рисков для сопровождения хорошо иллюстрирует картинка из ITIL: Полезность и гарантия услуги. Область рисков всегда находится в гарантиях – заказчик всегда хочет иметь гарантии своих инвестиций.

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

Кто эти люди? Как правило, это некие квалифицированные люди на стороне заказчика. Старшие бухгалтера, старшие расчетчики и так далее.

Насколько они обладают информацией о внедренном решении, настолько будет успешным и наше сопровождение. Они могут участвовать в разборе инцидентов, в формировании запросов на изменение и так далее.

Для этого им нужно иметь:

• модель компетенций – что они должны понимать, что именно им нужно знать;

• траектория обучения – у 1С есть все необходимое для обучения;

• база знаний;

• и расширенный доступ к функциональности системы.

Теперь – новая тема, создание Центров компетенций 1С на стороне заказчика.

У меня получилось описать технологию создания Центров компетенций заказчика, три уровня.

• Служба заказчика есть всегда.

• Центр поддержки – это когда подразделение заказчика имеет достаточные компетенции в области 1С и что-то берет на себя.

• И последнее есть практически во всех больших корпорациях – это объединенный центр обслуживания. Фактически, это внутренний франч, который является партнером фирмы «1С», но они, конечно же, привлекают и партнерскую сеть.

О людях.

Надо понимать, что те, кто делает проекты – это путешественники. Они любят риски, любят новые земли и очень скучают, когда сидят на одном месте.

Но есть и сопровожденцы – они садовники, они улучшают грядки и так далее.

Когда вы формируете у себя и команду внедрения, и команду сопровождения, имейте в виду, что нужно учитывать этот фактор.

Итоги и Вывод

1. Взаимодействуйте с командой проекта.

2. Документируйте результаты и создавайте базу знаний.

3. Формализуйте услуги и, если надо, заключайте SLA.

4. Автоматизируйте процессы. Я не сказал важный момент: в результате проекта всегда возникает технический долг. Он складывается из нескольких факторов:

   • Первое – это те запросы на изменение, которые идут в ходе проекта.

   • Второе – меняется функциональность типового решения, накапливаются те изменения, которые делает фирма «1С» или разработчики отраслевых решений.

   • И последнее – платформа тоже не стоит на месте. Все это формирует технический долг, и про него надо говорить, помнить и включать в стоимость сопровождения, возможно, создавая резервные фонды по завершении проекта.

5. Оптимизируйте и автоматизируйте процессы эксплуатации.

Если мы все это делаем – успех неизбежен.

Методическая поддержка процессов сопровождения со стороны вендора

Сервис «1С:Профкейс 3.0» – наше все. Там вы найдете все те методики, о которых я говорил.

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

Вопросы и ответы

Чтобы организовать сопровождение и сделать SLA, нужно какое-то нормирование. Как обеспечить это нормирование? Как знать, на какую услугу нам нужно подать какую трудоемкость, чтобы потом, подписав SLA с заказчиком, мы не остались без штанов?

Мы должны иметь две автоматизированные системы.

• Первая система – это наша обычная система Service Desk, которая учитывает объемные показатели предоставления услуг: количество запросов, по каким системам это было сделано и так далее.

• Вторая система – это система учета рабочего времени наших исполнителей.

Важно, чтобы эти системы были синхронизированы, чтобы люди отчитывались за те факты и события, которые зафиксированы в системе Service Desk. Объединяя эти данные, мы получим нормативы.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".