Как настроить правильную техподдержку (helpdesk, service desk на коленке)

Публикация № 1052789

Управление - Управление взаимоотношениями с клиентами (СRM)

процесс автоматизация техподдержка техническая поддержка service desk helpdesk тикет клиент заявка

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

Оглавление

Экономический эффект поддержки

Что это и для чего нужно 

Основные правила хорошей поддержки

Заключение

 

Статья большая, добавляйте в закладки, чтобы не потерять. Будут вопросы - заказывайте презентацию

 

Экономический эффект поддержки

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

 

  1. Косвенный. Как и от любых внедрённых бизнес-процессов вы получаете положительный эффект «в долгую». 
    1. В виде высвобожденного времени специалистов, которое сейчас тратится на хаотическую обработку заявок. Если вы читаете эту статью, такие заявки у вас, скорее всего, есть :) Будет система со сроками, будет автоочередь задач - все негативные моменты ручной диспетчеризации, жалобы по поводу забытых заявок уйдут, ответственности станет больше
    2. В виде дополнительной расположенности клиентов к вам - продлять поддержку, совершать доп. продажи лояльному клиенту проще
    3. Снижается вес риска ухода специалиста - если поддержка перестаёт быть уникальным знанием, то новые сотрудники быстрее входят в работу и это принципе возможно без краха системы
    4. Оцифровка и объективность данных - система фиксирует сроки обработки, ответственных, количество запросов, себестоимость заявок и прочее. Арбитраж ситуаций с недовольным клиентом («мне ни разу не помогли!»), с перегрузкой специалистов работой («не успели, потому что у нас 1000 задач!») и т.д. решаются по данным, а не по эмоциям. Можно планово масштабировать сервисы при необходимости. 
    5. Снижение излишних затрат. Частый пример, вопрос выходит за рамки поддержки, но специалист все равно его делает - по факту лишние затраты времени на пост-согласование с клиентом стоимости и возможности оплаты вообще, вместо предварительного согласования.
    6. Качество продукта растет. Процесс предоставления поддержки - это практически бесконечный процесс улучшений. Сейчас вы создадите одну версию, через месяц поймете, что, например, запросы вида «А как месяц закрыть?» должны решаться в другие сроки и не в режиме аврала - запустите их по иному маршруту сервиса. Если под качеством понимать соответствие заявленным стандартам, то тенденция безусловно будет положительной.
  2. Прямой. Тут больше подходит для внешнего клиента, но и для для внутреннего иногда применимо
    1. Соответствие лимитам. Количество услуг поддержки должно оказываться согласно тем договоренностям, что вы выставили. Если клиент свой лимит исчерпал, то система должна на это реагировать - предложить продлить сервис, перенести вопрос на другой период (в зависимости от того, что вы в процессе предусмотрите). 
    2. Контроль стоимости обращения. Это относится к инцидентной системе управления, задача системы - уметь инциденты создавать. Например, «превышен лимит затрат в 10 часов специалиста на заявку» - такой инцидент получит руководитель по факту его происхождения, а не случайно найдет в отчете через месяц. 
    3. Своевременное пополнение бюджета. «Здоровая» компания должна получать стабильное финансирование с определенной частотой. То есть, не «менеджер решил проверить, у кого поддержка заканчивается и сделать всем счета», а «система заранее подготовила счета клиентам согласно их запросам и запустила процесс контроля оплаты».

 

Картинка из разряда «Как процесс поддержки представить на графике». Подробнее о показателях дальше по тексту

 

к оглавлению

 

Что это и для чего нужно 

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

  1. Это сервис - у него есть свой порядок предоставления, рамки и правила. (По каким каналам и вопросам можно получать ответы, в какие сроки будет ответ)
  2. Сервис оказывается персонально - конкретному человеку (пользователю среды) по его конкретному вопросу. Это не обучение пользованием продуктом, это не справочник с общим доступом. Да, такие функции тоже должны быть в системе. Да, ответом техподдержки может быть ссылка на статью, решающая вопрос пользователя. Но как нельзя поддержкой называть общедоступную документацию, так и нельзя общаться с эмоциями вроде «У меня тут отчет запрашивают какой-то… А времени нет!».
  3. Среда должна быть определена. Ваша поддержка может быть точкой входа как для вопросов по 1С, по Windows, по почтовику, так и по предоставлению 2-НДФЛ, запросов на отпуск и т.д. Вы сами определяете спектр вопросов, которые будете решать в рамках этого процесса. У нас, например, и задачи собираются, и консультации оказываются и документы запрашиваются через «одно окно». 

 

Можно ли жить без такого сервиса? Да, бесспорно. Будет ли при этом у ваших сотрудников и клиентов меньше вопросов? Нет, они просто будут действовать как умеют (или вовсе не действовать, а жаловаться на тяжелую долю). Будут слать письма по почте с копией на всех и вся, тратить время своего начальника, бегать по офису и «пытаться решить вопрос». Кстати, гораздо хуже узнать через несколько лет работы, что ваши юристы тратят на один договор «от двух дней», вместо того, чтобы делать его за 30 минут в настроенной программе - просто потому, что однажды «что-то сломалось, а куда с этим идти-то, мы не знаем…», чем уметь обрабатывать такие ситуации. 

 

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

• Приказы уровня «по 1С обращаться напрямую к Андрею и не дергать бухгалтерию!», «2-НДФЛ выдается каждый четверг в порядке очереди в кабинете 218»

• Попытки свести поддержку в почту: «Пишите на help1c@supercompany.ru по 1С», «Не пишите на help1c@supercompany.ru по вопросам резервов, ими заведует кладовщик!». Бонусом получаем письма [RE:117 Ошибка!!!], где ведется переписка по разным вопросам за несколько месяцев - и уже никто не помнит, что нужно в итоге, обращения стихийно возникают в процессе и умирают.

• Супер-идеи - «Сейчас мы в 1С быстро напилим Заявку, сделаем статусы и будет счастье». Это действительно работает, пока есть 2-3 запроса в неделю. С ростом различных сервисов, вы начинаете постепенно захлебываться в количестве различных статусов «В работе», «Ожидает», «Передан в бухгалтерию» и т.д. - их, оказывается, тоже надо поддерживать. Добавить новый сервис - та еще головная боль, как это все работает знал только Петрович, который уволился на прошлой неделе. Иногда вашему монстру «Заявке» надо одновременно быть в двух статусах, например, «Согласована» и «В очереди на следующий месяц» - о таком лучше вообще не думать.

• Мы все поняли. Давайте развернем нормальный helpdesk. «Но только чтобы с там и договора согласовывать можно было! А еще нужен календарь!» и подбор «идеальной системы» на пару лет, в которой есть все-все-все и еще немного

• …

 

Как и с любым бизнес-процессом тут нужно работать итерациями, внедрять мелкие части процесса в работу, но делать это часто. Например, наш процесс оказания поддержки проработан и автоматизирован на 136 попугаев и 57% - есть куда расти

Но это нисколько не мешает нам работать по этому процессу уже сейчас - система настроена и обеспечивает качественное выполнение.

 

Мы построили довольно хорошую системы поддержки наших клиентов внутри своего основного продукта «Процессы 3». Она ни разу не претендует на звание «единственно верная и покрывающая любой кейс система поддержки», у нас тоже есть недовольные клиенты (претензии, кстати, тоже пришлось научиться обрабатывать), но все-таки одно неоспоримое преимущество у нее есть: наша система на 99% кастомизируема. Она построена на бизнес-процессах с дополнительными фишками вроде работы через браузер, почту, telegram, всеми любимыми статусами, календарями, отчетами, настраиваемыми рабочими местами и т.д. Даже сейчас мы меняем наши процессы работы поддержки прямо по ходу пьесы и от этого никто не страдает. 

 

Переходим к тому, что обязательно должно быть в системе поддержки и как это должно использоваться (все, о чем пойдет речь дальше - настроено в системе, а не запрограммировано кодом). Мы осознанно не будем углубляться в методологию, ваши пользователи, скорее всего, даже мельком про ITIL и иже с ним не слышали. 

 

Основные правила хорошей поддержки

Я могу выделить 9 пунктов, которые стоит продумать для того, чтобы вашу поддержку можно было назвать жизнеспособной:

  • Правила работы. Как работаем
  • Доступность и точки входа. Где работаем
  • Интерфейс. В чем работаем
  • Сервисы. По каким направлениям работаем
  • Взаимодействия. Как общаемся в процессе работы
  • Гомеостаз. Как поддерживается рабочее состояние процесса
  • Регламент и бизнес-процессы. Чем руководствуемся при работе
  • Приоритеты. Как выстраиваем очередь задач
  • База знаний. Где и как храним информацию

 

Разберем каждый из этих пунктов с небольшими примерами

к оглавлению

Правила работы

Все начинается с некоторого соглашения, в рамках которого вы будете оказывать поддержку. Как правило, не нужно расписывать талмуд на 1000 страниц, что вы будете делать, чего не будете (его банально не прочитают). Но обязательно нужно осветить:

  1. Место оказания поддержки. Куда пользователю нужно идти, чтобы получить помощь. Например, «Единый портал технической поддержки доступен по адресу www… Регистрация на портале происходит … ». Обязательно назовите этот ресурс, чтобы избежать дальнейшую подмену понятий, например «… (далее [Портал])».
  2. Состав поддержки. На какие вопросы пользователь получит ответ, на какие - нет. Не нужно обнадеживать себя - все равно вопросы будут не только из этого списка, поэтому и нужна квалификация вопросов, которую рассмотрим дальше, но правила следует описать все равно. Например, «На портале вы получите ответы на вопросы по функциям и возможностям Продукта, сможете зарегистрировать нового контрагента и согласовать договор» или «Вы получите доступ к сервисам технической поддержки по 1С, согласования договоров, инициации процедуры проверки контрагента, согласно Приказу №…». Важно простыми словами описать что будет - лучше написать меньше, а в инструкциях первой линии техподдержки уже прописать детальную квалификацию - Ваша задача не отпугнуть пользователя, но и не дать ложных надежд, что поддержка все сделает за него. Важно, что если вы даете клиенту (внутреннему или внешнему) вариативность сервисов, то следует в соглашении прописать эту вариативность «Критическими являются вопросы, поставленные с пометкой СРОЧНО. Вопросы генерального директора всегда ставятся с пометкой СРОЧНО». 
  3. Предмет поддержки. То есть, "как действовать для получения помощи». Нужно договориться, что будет «центром» обсуждения и уметь его правильно наполнить. Обычно запрос оформляется в Тикет (в нем фиксируется тема, добавляются файлы и описывается проблема). Тут самая важная часть - для клиента на один вопрос один тикет, но с разными статусами. Статусы показывают, что сейчас происходит с тикетом. У вас же по этому тикету создаются задачи - много, разные и без статусов. Так достигается максимальная кастомизируемость обработки заявки пользователя. Разные типы обращения должны обрабатывать разные люди по разным маршрутам, но клиенту это не интересно - у него есть вопрос, который должен быть решен, детали не волнуют. Еще раз - клиент создает Тикет, в тикете статусами отображается, на каком мы этапе. По тикету создаются задачи на сотрудников поддержки, задачи не видны клиенту. Мы подробнее это разберем позже, пока зафиксируем так. Соответственно, для клиентов поддержки желательно описать, как именно ставить задачи, что означают статусы и как будут приходить уведомления об их смене. 
  4. Максимальные сроки реакции. Пользователь должен знать примерные сроки реакции на вопросы. Например, «Техническая поддержка предоставляется в размере до 3 вопросов в день от пользователя, гарантированный срок ответа - 3 рабочих дня. Срок поддержки может быть изменен в связи с загруженностью службы». Это не значит, что вы не будете принимать больше 3 вопросов в день, это не значит, что на запрос «все пропало» вы будете неторопливо кликать на крестик закрытия окна, т.к. «Еще не пришло время». Это сроки для клиента, а ваши специалисты должны работать минимум в 3 раза быстрее. Вы должны влезть в этот срок в случае полного провала, когда умерли последние бэкапы и уволились все сотрудники, проще говоря :) Важно, что если у вас с клиентами вариативность сервисов, то в соглашении следует прописать эту вариативность «Реакция на критический запрос - 1 час, реакция на вопрос генерального директора - 1 час, без учета выходных дней». 
  5. Исключения из правил. Здесь следует описать, что делать, если что-то пойдет не так. Например, если поддержка не отвечает, пользователя не устраивает оказанный сервис или ваш портал недоступен. Например, «При недоступности Портала … направляйте запрос по электронной почте … с пометкой Технической поддержке», «Если у вас возникли вопросы по качеству оказания сервиса, то оставьте ваш комментарий по электронной почте …». 

 

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

 

Ну а клиентам мы записали и отправили простое видео с общим обзором «их стороны работы», посмотреть можно тут

к оглавлению

 

Доступность и точки входа

Система поддержки должна быть доступна пользователям в «онлайне» в виде приложения со своим интерфейсом. Идеально, если это будет браузер, который открыт почти всегда. Неплохой вариант, если это будет сервис внутри 1С или другой системы. Гораздо хуже, если вы решите поддерживать пользователей исключительно через почту, по телефону или мессенджеры. Важно! Задать вопрос и получить на него ответ можно через мессенджеры, звонки и письма, но обрабатывать эти обращения вы должны именно системно. Поддержка других каналов, скорее, бонус системы. У нее нет обязательного требования «оказывать поддержку там, где пользователю удобно», напротив, продуктом поддержки будет «вовремя обеспеченный знанием о продукте пользователь». Всегда нужно сначала выстроить систему поддержки с одним, но понятным входом заявки, затем уже анонсировать, что точек входа несколько.

 

Наши «Процессы» загружены в УНФ и опубликованы в вебе (забегая вперед, такой сценарий возможен и в отдельной базе, и внутри старенькой УТ 10.3). У нас прием заявок идет 

• Через специальное настроенное рабочее место клиента. Об этом знают все наши пользователи

• Некоторые заявки мы принимаем через форму обратной связи на сайте и письма. Об этом знают некоторые

• Задачу можно поставить в telegram-боте. Об этом знают единицы (вот, кстати, пример того, как можно с telegram систему подружить)

 

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

к оглавлению

 

Интерфейс 

Кто вообще работает в системе оказания технической поддержки? Тут по классике управления бизнес-процессами (если не знаете эту удобную классификацию, приходите к нам на бесплатные вебинары):

  • Инициатор тикета. То есть, сам пользователь 
  • Специалисты разных уравнений решения вопроса пользователя
  • Руководитель технической поддержки

 

У каждой из этих ролей должен быть свой интерфейс, у каждой роли свои потребности от системы. Минимальный состав элементов управления будет такой:

 

Инициатор тикета должен иметь возможность:

  • Создать тикет по нужному сервису
  • Посмотреть прошлые тикеты
  • Видеть оперативные оповещения от других пользователей системы (преимущественно, от специалистов)
  • Смотреть статьи базы знаний - правила и регламенты работы, важные новости

 

Рабочий стол клиента поддержки

 

Специалисты:

  • Видеть задачи по разным тикетам в порядке автоматического приоритета. Специалист не должен думать, что делать следующим шагом, всегда берем то, что имеет больший приоритет. В задаче специалиста уже содержится необходимая для решения тикета информация в зависимости от уровня поддержки - если это первый уровень, то это описание клиента, доступы к нему. Для второго уровня уже выводится оформленный комментарий от первого уровня поддержки.
  • Иметь доступ к статьям базы знаний и документации. Многие вопросы решаются просто ссылкой на документацию. Чтобы продолжать и дальше работать в этой удобной манере, документация должна быть пополняемой - это должно управляться прямо по выполнению процесса поддержки (ставиться задача на пополнение документации на первую линии поддержки).
  • Планировать работы по тикетам. Некоторые тикеты решаются в несколько приёмов и не за 5 минут. Работа по таким тикетам должна быть внесена в календарь для оценки занятости служб поддержки
  • Видеть личные показатели работы. «А насколько я в этом месяце исполняю план / закрыл задач / допустил ошибок?» - эта информация первое руководство к действиям ответственного сотрудника, которое должно быть перед глазами всегда
  • Видеть оперативные оповещения от других пользователей. Это обычная лента оповещений, как хроника в Facebook - уведомления в порядке их свежести

 

Оперативная страница специалиста-разработчика

 

Планирование задач специалиста-разработчика

 

Внешний вид задачи со встроенной справкой

 

Одна из рабочих страниц специалиста первой линии поддержки

 

Руководитель

  • Видеть происшествия, которые возникли по ходу процесса поддержки. Система должна мониторить важные вещи (потенциальные проблемы, как уже говорили выше) и оперативно создавать на руководителя задачу для ручного управления.
  • Видеть показатели процесса поддержки. Это может быть счетчики по важным областям, показатели работы сотрудников и т.д.

 

Оперативная информация

 

Динамика по количеству новых тикетов по дням

 

График затраченного времени поддержки по дням по клиентам

 

Контроль тикетов - доска из карточек «ожидают нас», «ожидаем мы»

 

Картина рабочего дня специалистов

 

Я прокомментирую некоторые обязательные, на мой взгляд, показатели, которые выводятся у нас на рабочем столе руководителя:

  • План / факт работ (день и неделя). Сколько запланировали и сколько успели из этого сделать
  • Просрочено задач в разработке. Сколько задач второй линии вышли из своего срока и по ним нужно разбираться с ходом работ
  • Количество ошибок за 14 дней. Баги, которые мы допустили в процессе разработки
  • Тикеты в работе. Общее количество тикетов, которое находится сейчас в работе для оценки общего уровня загруженности
  • Просроченные тикеты. Количество тикетов, процессы по которым просрочены. Должно быть 0
  • Время по клиентам. Сколько времени по поддержке потратили на тех или иных клиентов в день
  • Рабочий день сотрудников. Карта дня сотрудников, где видны отметки времени работы по задачам
  • Канбан-доска по активным тикетам в ключе «на чьей стороне мячик»
  • Динамика тикетов по дням возникновения. Чтобы отслеживать пики запросов

 

Показатели процесса - это как приборная доска, вы можете обращать внимание на что-то иное, главное, чтобы было на что обращать внимание :)

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

к оглавлению

 

Сервисы 

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

 

У нас есть несколько вариантов сервисов в рабочем месте клиента:

1. Вопрос по функционалу. Это самый сложный процесс, выдаваемый наружу. Тут внутри и вопросы к первой линии поддержки по функционалу Процессов, и указания багов, и предложения по доработкам.

2. Запрос документов. Если нужно получить от нас какие-то сканы или оригиналы

3. Запрос ключа к базе данных. Это автоматический процесс, который сам генерирует регистрационный номер для активации новой версии процессов, сам смотрит лимит по выданным ключам.

 

Для запуска каждого сервиса пользователю нужно нажать на соответствующую кнопку - тогда система создаст и откроет для заполнения тикет. Пользователь его наполнит (может в несколько этапов это делать, пока статус не поменяет, тикет будет в «черновиках»), прикрепит вложения и запустит в работу. Система тикет подхватит и запустит его в обработку. О том, как система обеспечивает получение пользователем ответа, рассмотрим в разделе «Регламенты». 

 

Это старт обычного процесса поддержки - по вопросу клиента

 

А это - старт другого процесса по запросу ключа к информационной базе. У каждого процесса свой маршрут (этот вообще полностью автоматический без действий пользователя).

 

Для пользователя запуск процесса начинается нажатием соответствующей кнопки в своем рабочем столе. Дальше уже система сама формирует внешний вид тикета в зависимости от сервиса

 

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

 

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

к оглавлению

 

Взаимодействия

В ходе получения поддержки пользователю нужно всего три вещи:

1. Получать обратную связь по прохождению тикета

2. Знать дату следующего шага. Это не обязательно дата и время, до которого пользователь получит ответ (тут уже от ваших соглашений зависит). Клиент чувствует себя спокойно, если знает, что «с его вопросом до такого-то числа что-то случится».

3. Получить ответ на свой вопрос в указанный срок

 

С пользователем должно быть налажено взаимодействие в рамках его вопроса. Клиент должен знать, что если он сделает такой такой-то набор действий, то его запрос примут в обработку. О том, что его запрос увидели, он узнает так-то и так-то. У пользователя сразу же рождается в голове «мини-проверка» - если мне не ответили в такое-то время, то что-то не так и стоит проверить, а туда ли я написал. К тому же, у пользователя должна быть возможность общаться в рамках своей заявки с «живыми людьми» - в комментариях к тикету важно иногда что-то спросить или уточнить срок.

 

У нас общение идёт в рамках тикета. Пользователь после создания тикета отправляет его в «плавание» по определенному маршруту. Система создаёт нашим специалистам задачи, что-то транслирует обратно в тикет. Но часто у пользователя возникают вопросы по ходу, например «А может быть вот так надо?». Чтобы такой вопрос не ломал цепочку задач бизнес-процесса (технически, процесс уже может быть далеко у программистов на анализе), в таком случае ответственный сотрудник поддержки подключается в тикет и отвечает на этот вопрос либо о том, что для анализа требуется время, либо принимая ответ пользователя и завершая процесс. Все вопросы клиента попадают в общую ленту рабочего места стола специалиста поддержки и обрабатываются по мере поступления. Тут не вводится дополнительных сложных правил - клиенты бывают разговорчивые и наоборот молчаливые - максимальный срок ответа 1-2 часа в рабочем интервале, часто обрабатывается раньше. Пользователь получит ответ оповещение об ответе на почту (или в telegram) - сможет так же на это письмо в почте ответить и оно прилетит обратно в задачу в 1С. 

 

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

 

Так выглядит тикет для клиента

 

А вот так он смотрится «внутри системы». Специалисты же получают задачи по каждой стадии этого тикета.

 

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

 

То есть, у нас есть универсальный документ, один из его видов мы настроили в «тикет», вокруг него прописали процессы, выдающие специалистам задачи. Клиент видит только тикет (в нем идет переписка, устанавливаются статусы, скидываются оповещения), специалисты работают по задачам процесса. Тикет один, задач много - согласно маршруту процесса.

к оглавлению

 

Регламент и бизнес-процесс

Тут начинается самое интересное :) Нам нужно обеспечить ожидаемые результаты по каждому тикету. Чтобы все тикеты обработались одинаково хорошо, нужно:

  1. Система маршрутизирует прохождение тикета в зависимости от сервиса
  2. Специалисты получают уведомления о новых событиях и знают, как их обрабатывать

 

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

 

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

 

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

  1. Вопрос по функционалу. Что-то спросили по программе - нужно в обычном режиме посмотреть документацию, ответить на вопрос
  2. Ошибка. Случилось что-то некритическое, например, в новом релизе допустили в коде баг, который не даёт создать группу побочного справочника 
  3. Критическая ошибка. Любая ошибка, которая делают работу невозможной: 1С перестаёт запускаться, шаблон процесса не создаётся, веб-клиент не открывается. 
  4. Предложение по доработке. Что-то из разряда «Было бы здорово, если бы вы добавили отображение всех комментариев в едином месте бизнес-процесса»

 

Классификацию нужно проводить потому, что она влияет на:

  • Сроки процесса
  • Схему обработки

 

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

 

Классификацию выполняет первая линия поддержки. Ее задача тут максимально выяснить, что клиент на самом деле хочет, постараться воспроизвести ситуацию и проверить на тестовой базе. Далее, если ответ классифицируется как вопрос по функционалу, то первая линия же и отвечает на вопрос, транслирует в комментарий тикета свой ответ. Пользователь получает ответ на почту (или в telegram), видит его в тикете и отписывается либо, что все ок, либо продолжает переписку. Первая линия поддержки по факту общения с пользователем либо завершает свою задачу ответа на вопрос с закрытием тикета, либо переводит его дальше с другой классификацией состояния. 

 

Схема работы первой линии поддержки довольно простая:

 

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

 

Для «ошибки» и «критической ошибки» формируется уже задача на разработчиков (следующая линия поддержки), система переносит в неё пояснения от первой линии, назначает задаче срок и приоритет. 

 

После выполнения задачи разработки нам нужно уведомить клиента, что ошибка устранена, функционал добавлен или запрос закрыт - первая линия поддержки получает задачу оповестить клиента о выполнении. Клиента оповестили, тикет закрыли, обратную связь получили - все довольны, все молодцы. 

 

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

  • Банальные правила работы с клиентом в профессиональном стиле (что делать, чего не делать, вежливо обращаться, но не работать за клиента - помогать в настройке)
  • Как квалифицировать обращения, по каким правилам
  • Какую информацию нужно у клиента уточнить для воспроизведения ситуации

 

Разработчики должны знать:

  • Правила приоритетов задач (критические решаются быстро и без разбора «кто виноват»)
  • Что такое «решить задачу» - некоторые думают, что его задача просто диагностировать ошибку и описать, когда она появляется

 

Правила тут следующие: «Пользователь поддержки должен получать решение своего вопроса в объёме и сроке, зависящем от дополнительной квалификации вопроса», «Специалисты всех линий оказания сервиса должны знать, что им делать и в какой срок»

 

Вся эта работа описывается несколькими регламентами - правилами работы специалистов, которые зафиксированы в системе, в дополнение система сама по этим регламентам выдает задачи. Для обычной поддержки клиентов по нашему основному продукту есть регламент «Поддержка» (инициатива идет от пользователя). По проектным работам, где важна другая оперативность работ, используется регламент «Оперативная поддержка» (инициаторы запросов - система автотестирования или пользователи). Мы сейчас рассматриваем общий случай с обычной поддержкой, если интересен второй - пишите.

к оглавлению

 

Гомеостаз

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

 

 

В то же время, не все действия обязательно выполнять сотрудникам. Например, если тикет висит давно, в нем нет ответов от клиента после нескольких наших сообщений, то такой тикет должен закрываться автоматом системой. У нас так работает для тикетов, связи по которым нет больше 3 дней. 

 

Правила: «Для корректного выполнения процесс поддержки должен быть снабжен «процессом-компаньоном», в котором сотрудники должны актуализировать состояние тикетов».

к оглавлению

 

Приоритеты

Как уже писали выше, сотрудник не должен думать, что и в какую очередь делать. Система приоритеты должна назначать сама. Это простое правило помогает сделать так, чтобы тикеты исполнялись не в зависимости от эмоций, а в порядке, настроенном шаблонами. Здесь сколько важен не сам приоритет, а то, что он в принципе существует и назначается в зависимости от каких-то данных. Например, у нас задачи первой линии исполняются в порядке возникновения, они, как правило, простые. А вот задачи второй линии уже лежат в рамках приоритизации в зависимости того, что внесено в задачу:

 

 

Правило: «Необходимо выработать ручные или автоматические правила приоритезации задач и тикетов заранее»

 

 

База знаний

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

 

Обязательные статьи базы:

  • Порядок работы с технической поддержкой. Для клиента
  • Порядок работы с клиентом по технической поддержке. Для наших специалистов
  • Описание-документация по частым вопросам или вашему продукту. Для клиентов (этот вид должен быть автоматически пополняем, но это уже другая история)

 

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

к оглавлению

 

Заключение

Словом, описание нашего процесса поддержки на текущий момент в цифрах можно представить так:

136 - общая оценка в баллах, можно сказать, «выше среднего». Значит, процесс хорошо описан и стабильно работает.

 

Это все - неполное описание процесса нашей поддержки. Есть еще куча тонкостей и моментов, которые в эту статью просто не влезли. Мы прошли довольно долгий путь по оформлению этого сервиса и набили кучу шишек). Если хотите так же и в вашей компании (а еще из без набивания шишек) - заказывайте презентацию, поможем!

 

к оглавлению

«Простые процессы»

38

Специальные предложения

Автор запретил комментарии

См. также

Работа с автозаполнением шаблонов файлов в документообороте 5

Статья Программист Нет файла v8 ДО Бесплатно (free) Практика программирования Документооборот и делопроизводство

При автозаполнении шаблонов файлов средствами MS Word возникает такая проблема - если одно и то же поле используется несколько раз в документе, тогда приходится дублировать закладки, например, если поле "Ответственный" используется 2 раза приходится создавать 2 закладки (Ответственный", "Ответственный2") и дублировать правила заполнения для этих полей. В данной статье я хочу рассказать каким образом можно создавать только 1 закладку и использовать данные из этой закладки в других местах документа.

22.09.2019    963    user995103    2       

Отображение истории выполнения по всем задачам комплексного процесса в документообороте 9

Статья Программист Нет файла v8 ДО Бесплатно (free) Документооборот и делопроизводство Практика программирования

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

15.09.2019    1248    user995103    0       

Как внедрить 1С:Документооборот в условиях хаоса 35

Статья no Нет файла v8 ДО УУ Документооборот и делопроизводство Бесплатно (free) Управление проектом

Не всегда проекты можно внедрить по заранее спланированному алгоритму. Скорее, даже никогда проекты не удается выполнить по универсальному плану: в каждой конкретной ситуации есть свои сложности и свои проблемы. Опытом внедрения 1C:Документооборот в отсутствии описанных процессов и утвержденной структуры предприятия на конференции поделилась руководитель отдела автоматизации торговой сети РЕМИ Марина Лимонтова (г. Владивосток).

21.08.2019    5011    limm28    10       

CRM PROF 1.4. Практика доработки 1

Статья Программист Пользователь Нет файла v8 1С:CRM УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Практика программирования

Статья описывает реальный опыт внедрения и доработки CRM PROF 1.4, а также показывает, какие были пожелания у заказчика и как они были реализованы. Статья предназначена для программистов 1С и пользователей CRM ПРОФ которые хотели бы расширить функционал программы.

08.04.2019    2176    script    0       

Механизм бизнес-событий на конкретном примере 29

Статья Программист Нет файла v8::Бизнес-процессы ДО Россия УУ Документооборот и делопроизводство Бесплатно (free) Управление бизнес-процессами (BPM)

Есть в системе 1С:Документооборот механизм бизнес-событий. Когда мне понадобилось решить конкретную задачу, гугление ни к чему конкретному не привело. Хотелось так «вжух» и всё понять про данный механизм, но в итоге пришлось лезть в код 1С и смотреть реализацию данного механизма. В данной публикации поделюсь результатами исследований, может, кому-то это поможет быстро и легко во всём разобраться.

18.02.2019    4897    soulner    0       

Вдохнем вторую жизнь во встроенный почтовый клиент из 1С:Управление торговлей 10.3 13

Статья Программист Нет файла v8 УТ10 УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Email

Хотели было воспользоваться почтовым клиентом из Управление торговлей 10.3, да не тут-то было. К сожалению, фирма "1С" почти совсем ее забросила и если Ваш респондент отправляет Вам письма, содержащие HTML, то Вас ждут матюки... Ну что же, как говорится: "Спасение утопающих - дело рук самих утопающих".

25.12.2018    4380    1c.pro.fun    8       

Воронка продаж в 1С: Управление торговлей v. 11. Рабочий вариант 7

Статья Пользователь Руководитель проекта Нет файла v8 v8::ОУ УТ11 УУ Управление взаимоотношениями с клиентами (СRM) Оптовая торговля Бесплатно (free) Бухгалтерский учет

Мы предлагаем рассмотреть альтернативную методику построения воронки продаж с использованием штатных средств 1С: УТ v.11. Этот подход опирается на типовые документы и механизмы, но, вместе с тем, на наш взгляд, дает руководителю более качественный инструмент управления при меньшем объеме трудозатрат на поддержание актуальной информации.

05.10.2018    4435    ЕленаЧерепнева    2       

Создание web-площадки на технологиях 1С, или как Водоканал сделал "Личный кабинет потребителя" 54

Статья Программист Нет файла v8 Энергетика и ЖКХ УУ Управление взаимоотношениями с клиентами (СRM) Дебиторская и кредиторская задолженность Бесплатно (free) WEB

Гончаров Максим делится опытом создания «Личного кабинета потребителя» на сайте водоканала. Он описывает архитектуру системы и объясняет, какую роль в ней играют технологии: «Битрикс», OData, веб-сервисы, «1С:БСП». Также в статье раскрываются возможности использования подсистемы «Анкетирование» в «1С:БСП» как конструктора документов.

25.06.2018    10460    maxx    31       

Интеграция Zimbra и 1С 22

Статья Программист Нет файла v8 Россия УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Внешние источники данных

В публикации описывается способ интеграции 1С с почтовым сервером Zimbra, используя SOAP сервис. Рассматривать вопрос интеграции будем на примере бизнес задачи, из блока CRM. Реализации общей адресной книги(GAL-Global Address List) между сотрудниками. Сотрудники(компания) ведет весь учет в 1С, в том числе и элементы CRM, а Zimbra выступает лишь в роли почтового сервиса. Сделать данную публикация побудило отсутствие в интернете готовых примеров совместной работы 1С и Zimbra. Надеюсь, она поможет кому-либо сократить время на реализацию похожей задачи.

16.04.2018    7286    Гексагон    17       

Настройка Рарус: СофтФон с SIP телефонией на примере оператора Телфин 7

Статья Системный администратор Программист Нет файла v8 1С:CRM Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Телефония, SIP

Описание настройки Рарус СофтФон для работы с SIP телефонией на примере конфигурации Управление торговлей и взаимоотношениями с клиентами (CRM), редакция 2.0.

26.02.2018    10838    de0nis    0       

Автоматизация для "полевых" сотрудников (тех, кто не работает в офисе) 42

Статья Программист Руководитель проекта Нет файла v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса УУ Учет рабочего времени Бесплатно (free) Управление бизнес-процессами (BPM)

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

24.01.2018    12128    siddy    0       

Внутренние бизнес-процессы 22

Статья no Нет файла v8::Бизнес-процессы 1cv8.cf УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Управление бизнес-процессами (BPM)

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

20.12.2017    11451    siddy    0       

Как мы визуализировали отдел продаж - графические отчеты для 1С 110

Статья no Нет файла v8 УНФ ERP2 УТ11 КА2 1С:CRM Россия УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Пользователю системы

После выполнения очередного проекта по автоматизации отдела продаж на 1С (конфигурация 1C:CRM 8, ред. 2.0) мы вдруг поняли, что чего-то не хватает. Странно: вроде и бизнес-процессы внедрены, и цифры в отчетах бьются, и заказчик в целом доволен. Но, реальным финалом проекта должна была стать визуализация данных по отделу продаж и установка TV-панели в кабинете у менеджеров по продажам.

05.09.2017    31322    aak_alexrovich_ru    56       

Переход на новые форматы ЭДО после 01.07.2017. (использование УПД) 14

Статья Бизнес-аналитик Бухгалтер Пользователь Нет файла v8 1cv8.cf Россия БУ Документооборот и делопроизводство Бесплатно (free) Пользователю системы

В статье я постарался кратко расписать, какие варианты обмена ЭДО с контрагентами доступны в 1С (любой конфигурации 1С) по новым форматам. Скрины новых форматов в списке картинок к статье. Добавил исправление поведения УПД при формировании ЭД.

25.07.2017    15177    igo1    10       

Обзор блока CRM в 1С:Управление торговлей 11 10

Статья Пользователь Руководитель проекта Нет файла v8 УТ11 Оптовая торговля, дистрибуция, логистика Россия УУ Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Пользователю системы Бухгалтерский учет

Да, этот блок в 1С:Управление торговлей 11 есть, и он достаточно функциональный. Возможно, этот обзор позволит вам избежать покупки дополнительных сервисов.

24.05.2017    17184    alis112358    4       

1С:Документооборот. Дополнительные обработчики бизнес-событий 16

Статья Программист Нет файла v8 ДО Документооборот и делопроизводство Бесплатно (free) Практика программирования

Есть ситуации, когда входящее письмо приходит из вышестоящей/контролирующей организации, зачастую со сроком исполнения "завтра". Поэтому разумно было бы в задачах рассмотрения иметь адекватный срок исполнения/рассмотрения. Если задачи рассмотрения создаются автоматически, тогда самым подходящим способом решения данной задачи будет пользовательский обработчик события.

03.05.2017    9890    aabogachev    1       

Добавление произвольной картинки (факсимиле, виза, подпись и т.д.) в шаблон документа (Microsoft Word doc., docx.) для конфигурации 1С: Документооборот 2.1 с минимальными изменениями в конфигурации 10

Статья Программист Нет файла v8 ДО Документооборот и делопроизводство Бесплатно (free) Практика программирования

В данном примере представлен небольшой сниппет для добавления картинок (подписи, визы, факсимиле) к шаблону документа (Microsoft Word doc., docx.) в системе 1С: Документооборот 2, используя типовую функцию вставки штрихкода.

28.02.2017    9722    Spartacus    1       

Документооборот: Перепоручить задачу из почты 17

Статья Программист Нет файла v8 ДО Россия Документооборот и делопроизводство Бесплатно (free) Практика программирования

Смысл доработки - в письмах-командах добавляется команда-ссылка "Перепоручить". При клике создается письмо, если в копию поставить email пользователей СЭД и отправить письмо, то данная задача будет перепоручена данным пользователям. Удобно для линейных руководителей - получив задачу от СЭД в почту, достаточно двух кликов, чтобы не заходя в 1С, поручить дело подчиненному.

13.02.2017    7150    aabogachev    4       

Управление договорами в 1С:Документооборот 19

Статья no Нет файла v8 ДО УУ Документооборот и делопроизводство Бесплатно (free) Управление бизнес-процессами (BPM) Пользователю системы Бухгалтерский учет

В 1С:Документооборот в релизах 2.1.7 и 2.1.8 концепция учета договоров продолжила свое развитие (появились стороны договора). Это повлияло и на бизнес-процессы (теперь вместо процесса Утверждение надо пользоваться процессом Подписание для договоров). Рассмотрим основные моменты, на которые надо обратить внимание при внедрении управления договорами в 1С:Документооборот.

24.01.2017    27283    vlush78    0       

Управление продажами в 1С:ERP 8

Статья Пользователь Руководитель проекта Нет файла v8 ERP2 УУ Управление взаимоотношениями с клиентами (СRM) Оптовая торговля Ценообразование, анализ цен Бесплатно (free) Бухгалтерский учет

Вводный обучающий курс по использованию 1С:ERP для управления продажами от Внедренческого Центра Раздолье. Автор курса Андрей Мироненко.

09.01.2017    14019    1СERP    0       

Добавление собственных "Автоподстановок" в 1С: Документооборот 16

Статья Программист Нет файла v8 ДО Документооборот и делопроизводство Бесплатно (free) Практика программирования

При внедрении 1С: Документооборот КОРП, столкнулся с необходимостью добавить свою автоподстановку. Автоподстановок давольно-таки много, но иногда нужно что то не типовое. Так получилось и в данном случае.

27.10.2016    15544    iolko    20       

Права доступа в 1С:Документооборот 2.1 40

Статья Системный администратор Программист Нет файла v8 ДО Документооборот и делопроизводство Бесплатно (free) Информационная безопасность

В программе 1С:Документооборот ред 2.1 механизм системы прав доступа сильно изменился. С одной стороны, права доступа в данной версии стали проще и быстрее, с другой стороны - права по рабочим группам объектов теперь могут противоречить политикам доступа. Разберемся в данной статье как работает механизм прав доступа в 1с документообороте 2.1.

16.09.2016    56881    vlush78    0       

Настройка бесшовной интеграции 1С: ERP 2.0 и 1С: "Документооборот" КОРП. Варианты реализации бизнес-процессов 88

Статья Системный администратор Программист Нет файла v8 ДО ERP2 ИТ-компания Документооборот и делопроизводство Бесплатно (free) Управление бизнес-процессами (BPM) Перенос данных из 1C8 в 1C8

Данная статья поможет настроить интеграцию 1С ERP и 1С "Документооборот" КОРП по технологии web сервисов. Описывается пошаговая настройка программ, а также приведены примеры процесса согласования договоров продажи контрагентам. Рассмотрены различные варианты реализации процесса согласования. Приведены примеры настроек маршрутизации процесса (условные и безусловные). В статье очень много скриншотов, может, кому-то это не понравится, но без этого считаю, что статья была бы не полной, т.к. описание именно "по шагам".

09.08.2016    58873    iolko    78       

Как организовать прогнозирование пробега автомобилей и приглашение на техническое обслуживание в Альфа-Авто 17

Статья Системный администратор Бухгалтер Руководитель проекта Нет файла v8 Автомобили, автосервисы Россия УУ Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Управление бизнес-процессами (BPM) Бухгалтерский учет

В данной публикации рассмотрим как на базе типового отраслевого решения Альфа-Авто организовать приглашение клиентов на периодическое техническое обслуживание (далее - "ТО") автомобилей с использованием расчетных данных о прогнозируемом пробеге. Основной идеей статьи является необходимость работы со всей клиентской базой (и их автомобилей) предприятия. Ниже будет описание того как нужно организовать процесс.

24.06.2016    57628    miavolas    21       

Новое в 1С:Документооборот ред. 2.1 10

Статья no Нет файла v8 ДО УУ Документооборот и делопроизводство Бесплатно (free) Пользователю системы Управленческий учет (прочее)

Фирма 1С не стоит на месте и продолжает радовать нас своими новыми версиями конфигурации 1С:Документооборот. В конце мая 2016 года вышла новая редакция 2.1, которая содержит как принципиально новые возможности, так и улучшение старых функций. В данной статье будут рассмотрены отличия конфигурации 1С:Документооборот редакции 2.1 по сравнению с редакцией 2.0.

15.06.2016    27526    vlush78    7       

1С:ERP Управление предприятием 2. Процессные сделки 9

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла v8 УТ10 ERP2 УУ Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Бухгалтерский учет

В продолжении рассказа о CRM подсистеме 1С:ERP Управление предприятием 2 я хочу рассказать, как в этой программе можно организовать работу по сделке с клиентом в виде бизнес-процесса, который последовательно расставляет задачи исполнителям, то есть ERP приобретает черты WorkFlow системы.

03.06.2016    13533    andironenko    1       

1С:ERP Управление предприятием 2. Создание сделки с клиентом 8

Статья Бизнес-аналитик Бухгалтер Руководитель проекта Нет файла v8 УТ10 ERP2 УУ Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Бухгалтерский учет

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

25.05.2016    14496    andironenko    1       

1С:ERP Управление предприятием 2. Сделки с клиентами 16

Статья Бизнес-аналитик Бухгалтер Руководитель проекта Нет файла v8 УТ10 ERP2 Россия УУ Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Бухгалтерский учет

Добрый день, меня зовут Андрей Мироненко, и я по возможности решил писать методические материалы по 1С:ERP Управление предприятием 2. С какой периодичностью я их буду выкладывать и как далеко продвинусь, пока не знаю, но буду стараться. Кроме этого, я пишу видеокурс по ERP (можно найти в разделе видео). Первая заметка посвящена использованию механизма сделок в ERP.

20.05.2016    14960    andironenko    2       

"1С:Договорчики" - инструкция по применению. Часть 1. Начало работы и создание шаблона договора 30

Статья Бухгалтер Руководитель проекта Нет файла v8 УУ Windows Документооборот и делопроизводство Бесплатно (free) Бухгалтерский учет

В конце 2015 года фирма "1С" выпустила продукт со скромным названием "1С:Договорчики". У продукта заявлен довольно неплохой функционал, делающий его пригодным для использования в небольших и средних организациях. По продукту мало методического материала. Я попытаюсь восполнить этот пробел несколькими публикациями.

15.02.2016    25010    portal_orsk    29       

Одна из причин медленной работы табеля (ЗУП 2.5, клиент-сервер, MS SQL Server) 61

Статья Системный администратор Программист Нет файла v8 ЗУП2.5 Россия Учет рабочего времени Бесплатно (free) Практика программирования Статистика базы данных Производительность и оптимизация (HighLoad)

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

19.01.2016    19742    KAPACEB.AA    16       

Нагрузочное тестирование 1С:Документооборот 30

Статья Системный администратор Программист Нет файла v8 ДО Windows Документооборот и делопроизводство Бесплатно (free) Производительность и оптимизация (HighLoad)

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

28.12.2015    18083    vlush78    1       

Подготовка к управлению проектами в 1С:Документооборот 15

Статья Пользователь Нет файла v8 ДО УУ Windows Документооборот и делопроизводство Бесплатно (free) Управление проектом

В рамках подготовки доклада "Использование 1С:Документооборот для управления проектом" для конференции 2015 подготовил базу 1С:Документооборот для демонстрации на живом примере.

22.12.2015    15532    vlush78    2       

Документооборот: Сложный порядок выполнения в Комплексных процессах, включающий сложные комбинации групп И и ИЛИ 3

Статья Программист Бизнес-аналитик Нет файла v8 ДО Документооборот и делопроизводство Бесплатно (free) Управление бизнес-процессами (BPM)

Комплексные процессы состоят из под-процессов «этапы». Эти «этапы» могут запускаться после «старта процесса» или выполнения других «этапов». Что мы имеем: Если этап должен выполниться, когда выполнился весь «набор этапов», то выбираем вариант «Стартовать действие после выполнения всех отмеченных ниже действий». Если этап должен выполниться, когда достаточно выполнения одного этапа из «набора этапов», то выбираем «Стартовать действие после выполнения любого из отмеченных ниже действий». По сути первое – это логическое И, а второе – это логическое ИЛИ. Проблема: Комбинация наборов этапов из блоков И и блоков ИЛИ на уровне расстановки галочек (в форме "НастройкаПредшественниковЭтапаКомплексногоПроцесса") не доступна. В статье предлагается способ настройки таких процессов, подразумевающий незначительную доработку 1С:Документооборот КОРП (1 фоновое задание и 1 константа).

09.09.2015    15809    kitaevay    5       

Контроль возврата оригиналов первичных документов в типовых конфигурациях (для бухгалтеров) 67

Статья Бизнес-аналитик Бухгалтер Пользователь Нет файла v8 1cv8.cf БУ Документооборот и делопроизводство Бесплатно (free) Бухгалтерский учет

Очень часто перед рядовым (и не очень) бухгалтером встает вопрос о том, как контролировать получение оригиналов документов от покупателей/поставщиков на примере типовой бухгалтерии. В статье опишем несколько методик учета и попытаемся раскрыть все плюсы и минусы каждой из них. Опытным бухгалтерам и программистам в статье может показаться все банальным, но я думаю, все равно будет полезно ее прочесть и, возможно, кому-то это поможет.

15.07.2015    27562    Diversus    18       

Внедрение электронного документооборота в большой компании 49

Статья no Нет файла v8 ДО Россия Windows Документооборот и делопроизводство Бесплатно (free) Управление проектом

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

05.06.2015    11167    alexbourne    12       

Опыт внедрения схемы позаказного снабжения в розничной сети со сложной структурой складов 39

Статья Программист Пользователь Нет файла v8 УТ11 Розничная и сетевая торговля (FMCG) УУ Windows Управление взаимоотношениями с клиентами (СRM) Розничная торговля Бесплатно (free) Управленческий учет (прочее) Бухгалтерский учет

В статье приводится опыт внедрения УТ11 в розничной сети. Приведено решение двух задач позаказного обеспечения розничной точки: 1. Перемещение товара со «Склада обеспечения» на «Розничный склад» по схеме «под заказ». 2. Закупка товара «под заказ клиента» на «Склад обеспечения» и дальнейшее его перемещение на «Розничный склад». Приведенное решение максимально использует типовую схему работы конфигурации Управление торговлей (11.1.9), но потребовало доработки ряда документов.

07.03.2015    27499    papche    16       

Контроль рабочего времени - синхронизация СКУД LYRIX с базами 1С: ЗУП 8

Статья Программист Нет файла v8 ЗУП2.5 Россия УУ Windows Учет рабочего времени Бесплатно (free) Практика программирования

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

12.12.2014    10669    nano1c    11       

"Процессы 3.0: CRM, Бизнес-процессы, Управление по целям". Универсальная система управления процессами и показателями для любой конфигурации 1С 99

Конфигурация Программист Бизнес-аналитик Пользователь Конфигурация (md, cf) v8 1cv8.cf УУ Windows Платные (руб) Управление бизнес-процессами (BPM)

"Процессы 3.0" - это подсистема для любой конфигурации 1С. Она управляет бизнес-процессами, считает показатели, зарплату сотрудников, создает интерфейсы. "Процессы" состоят из конструкторов, с помощью которых можно создавать бизнес-процессы, скрипты продаж, системы стимулирования, мотивации и многое другое без программирования.

48000 руб.

15.08.2014    45457    178    124       

Общие принципы формирования графика производства в новом решении "1С: ERP Управление предприятием 2.0" 15

Статья Программист Бизнес-аналитик Пользователь Нет файла v8 ERP2 УУ Windows Финансовый учет и бюджетирование (FRP) Учет рабочего времени Бесплатно (free) Управление бизнес-процессами (BPM) Бухгалтерский учет

Во второй статье, входящей в серию материалов, посвященных модулю производственного планирования в новом решении "1С:ERP Управление предприятием 2.0", рассматриваются особенности настройки графиков производства, в том числе интервалы планирования, расчет графика производства на верхнем уровне и выполнение графика на нижнем уровне.

21.07.2014    23498    itrp2013    2       

Инструкция по сегментации клиентов в 1C Рарус CRM 1.4-2.0 ПРОФ/КОРП 4

Статья Бизнес-аналитик Руководитель проекта Нет файла v8 1С:CRM Россия УУ Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Бухгалтерский учет

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

01.07.2014    17098    svcoopers    1       

Интеграция «1С:Управление производственным предприятием» с «1С:Документооборот» 62

Статья no Нет файла v8 КА1 УПП1 ДО Windows Документооборот и делопроизводство Бесплатно (free) Перенос данных из 1C8 в 1C8

В данной статье пойдет речь о возможности интеграции 1С:Управление производственным предприятием ред. 1.3 с 1С:Документооборот КОРП и о том, что может получить предприятие от этой интеграции.

18.02.2013    57208    Vladimir_Konyrev    38       

Интеграция 1С:CRM и Asterisk с помощью PHP-AGI и веб-сервисов 1C 17

Статья Программист Нет файла v8 1cv8.cf ИТ-компания Россия Windows Управление взаимоотношениями с клиентами (СRM) Бесплатно (free) Телефония, SIP

Давно зрел вопрос, можно ли встроить в диалплан Asterisk обращение к 1С:CRM системе для выполнения каких-либо управляющих действий и можно ли из 1С управлять IP АТС? Схема работы простейшая — при входящем звонке спросить у 1С что с ним делать, и если 1С ответила, то выполнить команду или продолжить стандартное выполнение маршрута вызова.

08.02.2013    28775    boffart    6       

Работа с PerCo своими силами 26

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Windows Учет рабочего времени Бесплатно (free) Внешние источники данных

Сейчас предлагаются различные готовые модули для работы PerCo с 1С. Но не всегда решение простых задач требует установки дополнительного модуля. Рассмотрим подключение для создания и изменения карт сотрудников.

03.10.2012    27653    Nas'ka    24