Организация эффективной техподдержки 1С внутри компании
Техническая поддержка пользователей 1С внутри компании одна из самых сложных и важных вещей в работе 1С-ника. Есть множество статей, книг, курсов, рассказывающих как правильно программировать, оптимизировать сервера, разрабатывать технические задания и большие базы данных. Но почти нет материалов по теме организации внутренней ТПД 1С. Парадоксально, но факт. Огромные усилия, затраты денег и времени могут вылететь в трубу, если сотрудник компании не сумеет воспользоваться всем этим.
Сразу встает образ того самого Excel — мощнейшего пакета, в котором встроены библиотеки прогнозирования, принятия решений, интеграция с различными источниками данных, свой язык программирования, макрорекордер, интеллектуальная среда разработки и еще огромная куча возможностей, но часто используется как «ну эта штучка, в которой таблички рисуют». Кстати таблички рисуют в Word, там реально удобней, требуется меньше знаний и сумма по колонкам есть. Но даже когда юзер и использует в Excel простейшие формулы типа «сумма», «если», «среднее», то остается целая пропасть между функционалом пакета и квалификацией секретарши. Например, один из моих преподавателей программирования имел дополнительный солидный заработок в крупном коммерческом холдинге благодаря знаниям возможностей MS Excel. Он прогнозировал цены на товары — в каком месяце года самые низкие, а в каком высокие. Только Excel, только статистический пакет и подгрузка данных прошлых периодов из различных торговых систем. Ну плюс живой ум и знание мат. аппарата. Разница между закупками-продажами и оптимизация складского хранения приносят миллионы прибыли.
И так, техническая поддержка пользователей 1С внутри компании (ВнТпд1С). Почему акцентирую именно на таком сочетании. Потому что есть много разных других видов технической поддержки и способов их организации. Соответственно продуктов и статей по ним. Есть много хороших, готовых вещей, которые не смотря на отсутствие русификации или открытого кода могут быть весьма доступными по цене. А если еще и в веб-исполнении, то даже бесплатными и уже с русифицированными пакетами. Потребуется сравнительно немного времени для инсталляцию и освоения пакета и задача решена. Но прежде чем тратить время на изучение стоит подумать как должна выглядеть ТПД, что она должна обеспечивать, для каких целей развертывается. Например вот моя условная классификация систем по целям ТПД:
* Тпд внешних клиентов — на коммерческой основе, соблюдение конфиденциальности, клиенты не видят друг друга. Хорошо подходят системы типа email-адрес, или в веб-исполнении тикет-системы (ticket-systems). Они не требует предварительных настроек на стороне клиента, клиенты не пересекаются между собой, но внутри компании сотрудники могут получить общую историю обращений. Системы ТПД никак не привязаны с ИТ-структуре клиента, нет возможности сделать предварительный технический анализ, получить дополнительные данные, воспроизвести ситуацию на данных клиента. Не помогает обеспечить контроль задач руководителями проектов, но можно использовать в случае возникновения спорных ситуаций.
* ТПД внешних пользователей. Это различные open-source проекты, коммерческой основы как правило нет, проще всего организовать в виде форума. Все все видят, участники стараются помогать друг другу. Потому что разработчики появляются редко, четких регламентов, обязательств и сроков по ответам нет. В общем или форумы остаются мало востребованными, пустыми или разрастаются в большую «мусорку» ответов, требуется модерация, накладные расходы на удаление флуда, отступления от тематик. Минусы — как и в прошлом пункте и еще потеря актуальности. Плюсы — самый доступный вариант организации для получения feed-back от пользователей, которые не доступны напрямую. В основном служит целям разработчика, улучшения продукта, нежели помощи конкретному пользователю в кратчайшие сроки.
* Общая внутренняя ТПД — «эникей», работа оргтехники, общесистемного ПО. Обеспечение работоспособности ИТ-инфраструктуры внутри компании. Самый распространенный вариант — телефон. Здесь главный показатель эффективности — скорость решения. Принтер не печатает, сеть пропала, не знаю что нажать. Квалификация обращающихся пользователей часто низкая — новичок, ламер. Источник едких шуток для опытных админов. Автоматизации почти не поддается. Не эффективно требовать от «юзверя» нажать правильные кнопки для оформления задачи «не знаю что нажать» или «сеть не работает».
Если пользователей стало больше 50 или количество обращений в день существенно увеличилось, то телефонный подход терпит фиаско. Телефон часто занят, или трубку не берут, потому что саппорт убежал чинить сеть, требуется больше времени на идентификацию — «какой Иванов звонит? какая 1С не запускается?». Логично увеличивают число саппортов и телефонов Сложно балансировать человеко-ресурсы. Или все без дела, или все разбежались\заняты. Тогда или саппортом занимаются сильные админы, начальники ИТ или «отказ в обслуживании».
В качестве автоматизации помочь может свободная система электронного обращения. Например внутренняя «аська», мессенджер. Помогает когда саппорт занят или отошел. Структурирования, обязательных полей не требуется (кроме «отправитель»), просто сам факт обращения в произвольной текстовой форме. Позволяет разгрузить и чуть-чуть улучшить очередь обращений. Но все равно ни пользователь, ни руководитель не видят общей загруженности исполнителя. Частые претензий «уже 30 мин как написал и тишина». Разрешить их невозможно. Нет контроля действительно забыл или занят. В общем работает только до тех пор, пока саппорт\админ успевает оперативно отрабатывать. Если в аську\почту написал и «тишина», то доверие пользователей к автоматизированным способам обращения подрывается и все возвращается к дозвону на телефон.
Это «свободная» или «стихийная» техподдержка. До тех пор пока всех устраивает — пусть работает. Это самое частая ситуация на практике. Для общей ТПД это терпимое зло, но такой способ организации не достаточен для техподдержки 1С. Если требования и уровень претензий растут, то такую ТПД тоже можно улучшить — сделать иерархичной, завести общую систему учета обращений и пр. Но подходы и средства будут несколько отличаться от техподдержки 1С.
Идентификация в службе ТПД
Еще один простой вариант автоматизации, снижения временных затрат. Как, например, у операторов сотовой связи. Если дозвонились, то на той стороне уже знают о вас многое — подключенные услуги, задолженность, ваш email и пр. Для целей внутренней ТПД упор надо делать на контакты, удаленное управление, средства диагностики. Для техподдержки 1С тоже актуально, потому что по 1С тоже бывает много «эникея». Можно эффективно организовать даже без автоматических определителей номеров и пр. технических сложностей. Ведь идентификатором может быть фамилия, учетная запись пользователя, адрес e-mail, учетка в 1С и т.п.
Панель удаленного управления Helpdesk Corp
ITIl — IT Infrastructure Library (библиотека инфраструктуры информационных технологий), Библиотека ITIL
При организации и классификации систем ТПД обязательно находятся те, кто говорит об ITIL. Кстати мне всегда интересно — говорят те кто прошел курс обучения, получил сертификат, применил на практике или просто говорят? У меня есть сертификат и все такое, но я предпочитаю не говорить Древние славяне хорошо знали земледелие и скотоводство, поэтому не хотели им заниматься. Иногда их угоняли в рабство, но и там они не работали. Но сейчас видимо немного придется.
Кстати о терминологии, часто встречаю как люди путают ITIL и 1С:ИТИЛИУМ. ITIL это библиотека. Т.е. набор терминов и определений, попыток формализации и описании моделей работы ИТ структур и автоматизированных бизнес-процессов. ITIL это даже не одна большая книжка по типу Большой Советской Энциклопедии, которую можно использовать как библию или первоисточник. В нашей стране это курсы и преподаватели, которые за деньги проводят обучение в крупных компаниях. Не дают никаких конкретных рекомендаций или софта, который способен реализовать все услышанное в полном объеме. Такие преподаватели даже между собой могут расходиться в определениях. Зато у них можно заказать консалтинговое обследование ваших ИТ бизнес-процессов и в качестве результата получить заключение. Ну бумажку или файл. Менять что то в системе все равно придется вам. Люди часто делятся на тех кто хорошо говорит и тех кто хорошо делает.
Иногда считается что «у нас полный ITIL» выполнив всего пару рекомендаций из всей библиотеки, в стиле кэп Очевидность, типа «тщательнее документируйте системы», «Наймите больше ИТ-специалистов», «используйте отказоустойчивое оборудование». Я считаю нельзя быть беременным чуть-чуть. Если у тебя ITIL значит уровни SLA, полная и всегда актуальная структура CMDB, Capacity и прочие Management, обязательная многоуровневая техподдержка с кол центром и пр. прелестями, есть люди которые постоянно этими занимаются (только этим) , а в серверной вместо бубна висит сертификат ITIL, выданный одной из аккредитованных организаций. Конечно есть и такие компании. Сертификация ITIL является одной из составляющих ISO:9001, который дает право международной торговли продукцией. Поэтому есть конфигурация 1C:Итилиум, купив которую можно в итоге получить этот сертификат. Если кому надо, вот цены http://www.itilium.ru/buy/price/
Я думаю менеджер выяснит насколько крутая ваша компания и от этого попробует выжать из вас денег от 300 тыр. до 500 и далее. Вы же не хотите сами делать обследование? А мы можем обучить ваших специалистов, чтобы они потом сопровождали, а вот у нас годовая подписка на форум всего 20 тыс. в год. Кстати возможно по окончанию проекта реальная ситуация с ТПД в компании только ухудшится. Это как при изобретении анестезии многие врачи сопротивлялись ее применению аргументируя тем, что трудно определить — больной уже мертв или еще нет. Снижение количества обращений это не всегда показатель эффективности ТПД. Но есть руководители ИТ которые идут на такую подмену понятий из соображений личного комфорта, расхождения с целями бизнеса или недостаточной квалификации.
На самом деле в сертификации и консалтинге по ITIL нет ничего плохого. Если компания вышла на международный рынок и может себе позволить оплатить такие услуги. Да и сама библиотека, конечно, штука полезная. Я всем искренне рекомендую по возможности сходить на курсы или поискать материалы в Сети. Это может натолкнуть вас на новые идеи по организации работы, ну и для общего развития тоже пригодится. Но в целом надо понимать, что библиотека ITIL была создана в 80-е годы, по заказу Британского правительства, возможно даже Британскими учеными Цель — Разработать принципы эффективного и рентабельного использования ИТ-ресурсов. Результат их работы это ITIL (IT Infrastructure Library) как библиотека передового опыта организации ИТ (best practice). Ну т.е. понятно да? 80-е годы это такая древность для современной 1С, да еще и в Англии… например в западных компаниях от 100 сотрудников принято содержать отдельного Администратора Каталога — парень, который учетки в ActiveDirectory делает. Зато да, контактные данные, принадлежность к отделам, должности, права доступа, групповые политики — все персонализировано и всегда актуально. На этом сервере каталогов строится вся ИТ-структура, в том числе и техподдержка — оперативная и эффективная.
Хорошо организованная структура ИТ опирается на три кита и может оставаться на плаву хотя бы на двух из них:
— качественная разработка ПО (собственного или стороннего) (1)
— наличие регламентов (инструкций, базы знаний, обучения) (2)
— качественная техническая поддержка (3)
(1) хорошо разработанное ПО содержит документацию, в нем легко ориентироваться, малое количество сбоев, ошибок, непонятных ситуаций. Можно разобраться самостоятельно.
(2) пользователи знают какие кнопки жать, почему именно их, описание бизнес-процесса дает понимание процесса и результата, могут отличить баг от фичи
(3) ей можно легко воспользоваться (она хотя бы не постоянно занята), получить приемлемый ответ в кратчайшие сроки, не остаться демотивированным для последующих обращений. Вспоминается старый анекдот про Шерлока Холмса:
Шерлок Холмс и др. Ватсон летят на воздушном шаре. Поднялся сильный ветер, вырвал карту из рук, замотал шар, угнал за облака и окончательно сбил их с курса. Но тут шар начал снижаться, в облаках просвет, на нем поляна, овечки и пастух. Шар опускается все ниже и ШХ кричит пастуху:
— Милейший, подскажите где мы находимся!
Пастух медленно посмотрел на них, подумал и ответил:
— Вы находитесь на воздушном шаре!
Ветер снова угнал шар вверх, они летят и молчат в полной растерянности. И тут ШХ нарушает молчание:
— Странная местность, Ватсон, возможно это поможет нам определиться. Вы не знаете где программисты пасут овец?
— А с чего вы взяли что это был программист?
— Ну как, прежде чем ответить он подумал. А потом дал абсолютно точный ответ, но не применимый на практике!
* Внутренняя техподдержка 1С
Сопровождение пользователей по 1С одна из самых сложных задач. Потому что, одно дело комп не включается и совсем другое — месяц закрывается не правильно. Тут надо быть и специалистом в бух.учете, и разбираться в хитросплетении библиотек кода с отладчиком наперевес, и оставаться адекватным человеком ). Эникейных задач по 1С тоже много, но главное организовать помощь и в более сложных ситуациях. В отличие от «эникейных» требуется вдумчивый подход, отладка, воспроизведение ситуации от имени и на данных пользователя.
Если сотня пользователей замыкается на одного, двух программистов 1С то это крах. Программист не может программировать. Только ушел в отладку — звонок. Сразу с порога может обрушиваться сложная проблема — «у меня месяц не закрывается, что мне сказать директору?». Десяток мелких обращений могли бы быть решены играючи, но программист занят сложными вещами, или просто уже задерган и раздражен. У кого то всколыхнулись в груди неприятные ассоциации? А потом профессиональное выгорание, конфликты, поиск новой работы В общем все как в сказке — чем дальше тем страшнее:
У меня зазвонил телефон. Кто говорит? - Слон. - Откуда? - От верблюда. - Что вам надо? - Шоколада. - Для кого? - Для сына моего. ... А потом позвонили зайчатки: - Нельзя ли прислать перчатки? А потом позвонили мартышки: - Пришлите, пожалуйста, книжки! А потом позвонил медведь Да как начал, как начал реветь. А потом позвонили цапли: - Пришлите, пожалуйста, капли: Мы лягушками нынче объелись, И у нас животы разболелись! И снова медведь: - О, спасите моржа! Вчера проглотил он морского ежа! И такая дребедень Целый день: Динь-ди-лень, Динь-ди-лень, Динь-ди-лень! То тюлень позвонит, то олень. полный текст http://krotov.info/lib_sec/24_ch/chuk/ovsky.htm |
«Эникей» по 1С тоже нужен. И также как и по другим случаям требует оперативного контакта с пользователем. Тут или ноги или телефон+удаленное подключение. А более сложные задачи, просьбы о доработках, требуют обязательной регистрации для вдумчивого воспроизведения и поиска решения. Поэтому важно делать техподдержку 1С иерархичной. Но с оглядкой на наши реалии. Кстати, даже у крупных компаний могут быть узкоспециализированные БД, в которых работает только ограниченное число пользователей. Скажем не более 30. И они могут все находиться в головном офисе. В таком варианте иерархичность ТПД принесет только вред и лишние накладные расходы. Здесь лучше использовать одноуровневую схему с общим доступом, а возможно и тикет-систему. Т.е. по каждому сервису или базе данных решение о порядке и способах ТПД надо принимать индивидуально.
Helpdesk Corp позволяет организовать и одноуровневую ТПД по выбранным сервисам.
Как организовать иерархию ВнТпд1С на практике? Можно поискать резервы для первой линии ТПД без увеличения штата. Как правило это либо механизм экспертов либо админы филиалов. Экспертом может быть начальник подразделения, как носитель знаний предметной области, или один из квалифицированных сотрудников отдела. Требования не глобальные — взаимодействовать c вами, кратко и по существу формулировать обращения, опытный пользователь 1С. Первая линия отсекает «эникей», разгружает точки входа в ТПД.
Делай раз — кнопка такая то
делай два — на экране выскочит такая то форма.
….
счастье
В большинстве случаев инструкции в стиле чтобы сохранить, нажмите «сохранить», чтобы закрыть нажмите «закрыть» говорят о сразу о многом:
1. у вас нет пользователей (есть кнопкодавы, зомби, которые не понимают что делают. В любой отличной ситуации все встанет)
2. у вас нет ИТ-специалистов (возможно есть сотрудники ИТ, админы, программисты, но нет людей которые понимают структуру ИТ, ее цели, потребности и могут их обеспечить)
3. у вас нет справочной системы. (стандартные приемы работы с программой пользователи должны и так знать. А неявные, типа описание кнопки «Заполнить» — чем именно будет заполняться, откуда берется, что влияет — должны быть встроены в справку программы. Справка программы это не тоже самое что и база знаний. Это как Карл Маркс и Фридрих Энгельс — два разных человека, которые работали на одну общую цель, помогая друг другу)
Хорошо помогают видео-инструкции, вместо тысячи слов. Но это отдельный навык, который надо «прокачивать» — подбирать инструментарий, иметь закрытую аудио-комнату, не елозить мышкой и пр. Кстати можно начать тренировать этот навык уже сейчас. Это в любом случае вам вернется сторицей.
Конечно, если квалификация позволяет, то лучше развернуть внутренний сайт на одном из бесплатных движков. Если брать различные WIKI (doku-wiki, media-wiki и пр) то сразу учитывайте:
а) нет каталогизатора, меню, структуры. Все попытки и плагины это притягивание за уши. Движок вики это все знания обо всем. Для целей ВнТпд удобнее опираться на структуру — список сервисов, разделы администрирования, внутренней документации и пр.
б) создание\редактирование статей на вики-движках отличается от привычного вам способа. Возможно для вас это будут лишние знания, от которых лучше воздержаться.
Я рекомендую WordPress. Это одна из самый популярных cms, доступно много русских справочных материалов, форумов, там удобный визуальный редактор, много готовых плагинов, требуется меньше всего знаний для инсталяции и администрирования.
В базе знаний хорошо завести раздел «staff only» — для админов и разработчиков головной организации. Т.е. следует предусмотреть средства разделения доступа. Конечно файлы с паролями там хранить не надо, но какую-то внтуренню документации по структуре серверов, ЛВС и баз данных возможно придется. Это перекликается с умными словами из ITIL типа CMDB, Change Managment и пр. Но не обязательно загонять себя в рамки, но в каком то слабострукткрированном виде всегда можно хранить что то полезное.
Поддерживать актуальность
Сервисы и базы данных развиваются, меняется интерфейс и функционал. Надо отслеживать соответствие документации, своевременно вносить изменения. Можно взять за правило каждый новый функционал или изменение заканчивать рассылкой документации пользователям. Отправлять следует уведомление, ссылку, а не само содержание. Даже если вы еще не сделали ничего глобального, то все равно и вам и пользователям все равно будут полезны записи в стиле «адресная книга в почтовой программе теперь синхронизируется с сервером каталогов, новых сотрудников можно поискать нажав кнопку… (далее скрины или видео)»
также полезно в начале статьи указывать версию программы и дату. Это позволит пользователям сориентироваться если вы все таки забудете обновить документацию.
База Знаний VS техподдержка
Лучше разграничить эти понятия и делать упор на взаимодействие. Например в БЗ можно один раз дать описание какой-то функции, а потом в 10-и задачах ТПД давать ссылку на эту статью. Или наоборот — проанализировать самые частые причины обращений в техподдержку и подготовить одну статью или FAQ.
Таким образом контекстный поиск в ТПД, или в истории рассылок будет выводить пользователей на БЗ. Со временем в статье БЗ возможно что то измениться, дополнится, и ссылки останутся.
No Spam
Вроде бы всем понятно за что дают «по звездочке» — запросу типа
select * from *
Но и массовые рассылки, типа
net send *
— не меньшее зло. Надо стараться сегментировать рассылки с уведомлениями по БЗ. Сотрудникам бухгалтерии отправлять только новшества 1С:Бухгалтерии, расчетчикам — ЗУП. В том что пользователи не читают справки вина не только пользователей но и айтишников. Писать надо хорошо, рассылать правильно. Подорвав авторитет к БЗ и рассылкам можно свести все усилия на нет.