Как поддерживать нетиповую конфигурацию 1С

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

Таким образом, под наше определение попадает масса вариантов – от раритетных 7.7. до существенно модифицированных 8.3. Однако, именно неспособность обновляться стандартными средствами объединяет это разномастное множество, и допускает применение к ним единого подхода при организации поддержки.

Поддержка в таком случае распадается на несколько независимых «веточек»

Поддержка пользователей

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

Поддержка приложений

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

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

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

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

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

Именно для таких ситуаций были придуманы службы поддержки, организованные по принципам SLA (service level agreement, соглашение об уровне сервиса).

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

Обеспечивается это следующими средствами:

1. Поддержка принимается от клиента. То есть существует период, когда специалисты службы поддержки перенимают опыт и фиксируют его в виде регламентированных процедур и документов.
2. Поддержка, построенная по принципу сервиса, всегда предполагает резервирование сотрудников – никто не является единичным носителем компетенции. Как минимум, необходима замена на период отпусков и больничных; в отдельных случаях, когда сервис работает по сменам, то каждая смена должна обладать одинаковой компетенцией.
3. У сотрудников поддержки имеется «насмотренность» – так как они работали с множеством клиентов и множеством разных конфигураций, они хорошо представляют вариативность, им проще разбираться даже в сложных случаях (это как у хороших музыкантов: есть «наслушанность» на музыкальные произведения, когда по нескольким нотам они могут продолжить играть сложное произведение).
4. Если клиенту такой поддержки требуется передать компетенцию внутреннему сотруднику, то все решается очень быстро через совместную работу и обучение. Например, в короткие сроки можно обучить заместителя главного бухгалтера специфике выполнения регламентных процедур именно для этой компании.
5. И последнее: поддержка по SLA закрывает акт и получает деньги именно за качественное завершение определенных процессов, например – закрытия периода. Т.о. должная компетенция равно заработок такой поддержки. Этот принцип позволяет выстраивать многолетние партнерские отношения на четко определенных принципах и измеримых метриках.

Если вопрос поддержки «необновляемого» приложения или пользователей такого приложения для вас актуален, то читайте о том, как мы делаем поддержку по SLA здесь или оставляйте заявку.