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

26.01.24

Программная инженерия - Сопровождение

Есть ли жизнь после проекта? Если мы хотим жить долго и счастливо, нужно заранее подумать о том счастье, которое возникает после проекта. Чтобы это счастье случилось, мы должны пройти пять шагов к этому успеху. О том, как организовать базу знаний о внедряемом прикладном решении и какая информация понадобится, чтобы принять ИС на сопровождение, расскажем в статье.

 

Меня зовут Владимир Павлов, я руковожу направлением корпоративного сопровождения в фирме «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. Объединяя эти данные, мы получим нормативы.

 

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

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

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Мастер-класс: 8 бед, один ответ – корпоративное/постпроектное сопровождение

Сопровождение Бесплатно (free)

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

26.01.2024    670    0    user1947679    0    

3

Миллионы на сопровождении

Сопровождение Бесплатно (free)

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

23.10.2023    976    0    nelatontsev@webgk.ru    5    

6

Миллион на техподдержке. Правильная организация процессов внутри отдела

Сопровождение Help desk: Служба поддержки Бесплатно (free)

Исполнительный директор компании «Гильдия консультантов» Николай Елатонцев на конференции Infostart Event 2021 Post-Apocalypse рассказал, как организовать процессы техподдержки, чтобы это направление бизнеса стало прибыльным и прогнозируемым. Он поделился опытом, как правильно составить договор на техподдержку, зачем фиксировать каждую транзакцию по задаче, и как уведомления помогают в исполнении SLA.

13.03.2023    1897    0    nelatontsev@webgk.ru    8    

13
Оставьте свое сообщение