Что за программа клиент сервис

Привет! У SM Lab есть ключевой заказчик, как вы понимаете — это Спортмастер. В Спортмастере используют информационную систему Client Service Management (далее по тексту – CSM), предназначенную для обеспечения необходимой информацией сотрудников операционного центра (далее – ОЦ) и сотрудников контактного центра (далее – КЦ). Кроме сотрудников ОЦ и КЦ, к нашей системе имеют доступ различные подразделения компании, а также сотрудники розничных магазинов. В общей сложности у нас около 1000 уникальных пользователей ежедневно.

Меня зовут Павел Жилкин, я ведущий аналитик Департамента системного анализа SM Lab, и в этом посте я расскажу про работу системного аналитика и организационный подход в продуктовой команде, которая и занимается разработкой CSM.

Вот из каких частей сейчас состоит основная функциональность системы:

1. Регистрация и процессинг обращений от клиентов: претензии, благодарности, консультации.
2. Просмотр и редактирование заказов: способы получения, логистика, клиентские данные, клубная программа.
3. Просмотр карточки клиента клубной программы, редактирование анкетных данных, коммуникации, история начислений и списаний бонусов, покупки.
4. Регистрация новых клиентов клубной программы.
5. Поиск и просмотр подарочных карт и многое другое.
6. Просмотр и возврат оплаты по заказу.

О продукте, интеграциях, технологиях

Если верить Jira, первая задача в нашем проекте была создана 10.07.2013, так что CSM развивается уже более 9 лет. В 2020 году было решено переписать код приложения CSM, так как в первой версии функционал был реализован с использованием старого фреймворка GWT (свободный Java-фреймворк, который позволяет веб-разработчикам создавать приложения) и Oracle PLSQL (PL/SQL — язык программирования, процедурное расширение языка SQL, разработанное корпорацией Oracle).

Как создать качественный клиент-сервис? Отдел продаж с нуля под ключ.

Изначально логика CSM была реализована в хранимых процедурах, а монолитная архитектура не позволяла реализовывать требования от бизнеса в установленный срок. На данный момент приложение можно разделить на 2 версии: CSM1 и CSM2. В новой версии реализована микросервисная архитектура, логика переносится в Java, проводится редизайн системы и переход на новый фреймворк vue3.

Количество интеграций приблизилось к двадцати, уникальность приложения заключается в том, что мы интегрированы как с бэкофисными системами, так и с фронтофисами, кроме того, имеются интеграции с внешними сервисами. Из-за большого количества интеграций и разных по специфике систем наше приложение использует разные интерфейсы для интеграции начиная от веб сервисов REST API, WSDL и заканчивая интеграциями Oracle to Oracle, что в свою очередь требует от аналитиков умения использовать различные инструменты. В нашей команде мы работаем с SoapUI, Oracle SQL Developer, Postman, Swagger, Elasticsearch и другими.

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

Клиент-серверная архитектура в картинках

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

Основная проблема при переносе раздела была в том, что наше “производство” нельзя было остановить, и зачастую задачи приходилось делать параллельно в старом и новом приложениях, так как на перенос одного раздела уходило достаточно много времени. Часто приходилось искать компромисс и изобретать, например, был реализован новый метод для второй версии, а в первой версии стек технологий был другим. Чтобы хоть как-то сэкономить ресурсы разработчиков и не дорабатывать хранимые процедуры, первую версию тоже переводили на новый метод.

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

Команда и организационный подход

Параллельно с разработкой и переносом пользователей началась трансформация команды в период Covid-19 ограничений, поэтому выстраивать новые процессы приходилось в онлайне. Как вы знаете, в период ограничений наши розничные магазины были закрыты, продаж тоже не было, многие команды работали 247, чтобы запустить онлайн-выдачу заказов, а тут еще и новые члены команды, которые требовали погружения в проект.

Новый состав команды предполагал наличие следующих ролей:

1. Product Lead,
2. системных аналитиков,
3. разработчиков Oracle,
4. Backend,
5. Frontend,
6. тестировщиков,
7. дизайнера.

В процессе становления продуктовой команды мы проработали основные этапы развития команды.

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

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

1. Правила работы с jira – документ описывает типы задач, которые использует команда в пространстве jira.
2. Шаблоны задач – для каждого типа задачи проработана статусная модель и подготовлены типовые шаблоны, для ускорения процесса оформления задачи. Подготовлены шаблоны критериев приемки.
3. Правила работы по задачам эксплуатации – регламент для ведения сопровождения ИС, группой эксплуатации и команды CSM.
4. Правила декомпозиции задач.
5. Правила совместной работы над задачами – были прописаны критерии завершенности DOD и критерии готовности задачи к взятию в работу DOR.
6. Правила ведения документации и запросов на изменения.
7. Для каждого департамента были оформлены страницы с всей необходимой информацией для ускорения процесса адаптации новых сотрудников в команде.

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

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

Если задача требует участия нескольких команд, то обязательно заводится Cross Team Epic (далее – CTE), задачу берет в работу одна из команд архитекторов и прорабатывает архитектурное решение, команда участвует в защите и формализует задачу в своем пространстве. Департамент клиентского сервиса или операционный центр работают с продуктовыми эпиками, в случае если продуктовая задача требует работ смежных систем, то она должна заводиться как CTE. Мелкие доработки, технический задачи и баги поступают от разных источников. Группа эксплуатации может заводить задачи на консультацию, которые после разбора проблемы преобразуются в баг или в мелкие доработки. Технические задачи могут поступать от смежных команд или заведены участниками команды в случае, если есть необходимость таких работ.

На сегодня команда достигла зрелости и самоорганизованности, процессы непрерывно совершенствуются и развиваются. В команде:

• 1 PL
• 4 аналитика.
• 1 дизайнер.
• 3 backend-разработчика.
• 2 frontend-разработчика.
• 2 database-разработчика.
• 5 тестировщиков.

Члены команды активно принимают участие в жизни продукта, развивают t-shape, делятся опытом и знаниями, открыты к любому сотрудничеству и развитию. В команде выстраиваются процессы ревью аналитики, добавлен новый этап ревью требований отделом обеспечения качества. Команда отказалась от релизных циклов, двигается в сторону непрерывного потока поставки ценности, за AW23 команда выпустила 35 релизов и 305 задач.

Системный аналитик в команде

В нашей команде системный аналитик работает с разными задачами. При проработке задачи Cross Team Epic на несколько команд аналитик может выступать в качестве эксперта по системе, помогает описать список изменений в системе. Участвует в проработке и защите архитектурных решений.

Если задача продуктовая, то аналитик детализирует задачу на продукт. При проработке продуктовой задачи нужно уметь:

1. Работать с бизнес-требованиями.
2. Проводить сбор требований с product owner`ом.

Если требования собраны и все встречи проведены, тогда аналитик приступает непосредственно к проработке запроса на изменение (CR – Change Request). Этот документ включает в себя:

1. Описание постановки для разработчиков.
2. Работа с диаграммами (UML, BPMN) описание взаимодействия Backend, Frontend. Описание интеграционного взаимодействия.
3. Работа с базой данных, описание новых таблиц, выборка тестовых данных.
4. Подготовка REST, SOAP-запросов. Описание полей.
5. Описание маппинга полей, если интеграционное взаимодействие.
6. Проектирование интерфейса.
7. Описание пользовательских путей.

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

1. Менеджер сервиса запросов – отвечает за управление потоком запросов, проводит собрания по пополнению.

2. Менеджер сервиса поставки – отвечает за поставки запросов, оповещает пользователей об установке обновлений, включает фичатоглы.

3. Тестировщик – если есть необходимость, то участвует в приемочном тестировании.

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

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

1. Просмотр записей экранов пользователей, если они есть.
2. Просмотр логов в Kibana.
3. Воспроизводят ошибку на тестовых окружениях используя инструменты: SoapUI, Oracle SQL Developer, Postman либо интерфейс приложения.

По результатам разбора заводится дефект либо проводится консультация пользователей.

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

• Блог компании Sportmaster Lab
• Программирование
• Анализ и проектирование систем
• Управление продуктом
• Карьера в IT-индустрии

Источник: habr.com

Зачем вам нужно автоматизировать клиентский сервис

У каждой компании есть своя стратегия работы с клиентами. Одни открываются всем, оказывают максимально высокий уровень сервиса — даже если это идет в ущерб экономике бизнеса. Другие, наоборот, выбирают стратегию защиты. Есть и третьи — те, кто выбирает комбинированный вариант, делит клиентов на категории и дает им разный сервис.

723 просмотров

Автоматизация клиентского сервиса как раз позволяет управлять балансом между выгодой для бизнеса и качеством обслуживания. Разберем подробнее.

Из чего состоит клиентский сервис

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

Элементы клиентского сервиса:

• клиент — это ядро, вокруг которого строится сервис,
• клиентское соглашение — основной “закон”, по которому работает сервис,
• бизнес-процессы — все, что делает компания, чтобы выдать результат клиенту.

Клиенты и что о них нужно знать

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

Как только в компанию поступает звонок или сообщение, по номеру телефона “подтягивается” вся собранная информация и становится доступна оператору. И он понимает, как работать с этим клиентом, куда его направить и что предложить.

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

Какими бывают клиентские соглашения

Клиентские соглашения регламентируют всю работу компании с клиентами. Они могут быть как внешними, так и внутренними.

Внешние — это то, что мы транслируем клиентам. Соглашение об уровне сервиса (SLA, Service Level Agreement) — это договор между клиентом и компанией, который регламентирует параметры услуги или товара. Может заключаться с каждым клиентом либо при массовом сервисе представлять собой публичную оферту.

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

Внутренние соглашения — здесь речь идет о соглашении операционного уровня (OLA, Operational Level Agreement). Иначе говоря — как сотрудники компании между собой решают, какие действия они будут предпринимать между собой, чтобы решить запрос внешнего для них клиента.

Бизнес-процессы

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

При автоматизации сервиса процесс запускается быстро, с минимальным вовлечением персонала.

Для чего все это

Что в совокупности дает автоматизация клиентского сервиса:

• Растет эффективность бизнеса. Ресурсы любой компании ограничены, поток обращений большой, невозможно к каждому клиенту прикрепить специалиста, чтобы тут же обработать обращение. Автоматизация позволяет сократить количество задействованных сотрудников (снизить затраты на ФОТ), а также максимально рационально использовать время остальных.
• Экономится время. Это происходит за счет того, что доля ручного труда минимизируется настолько, насколько это возможно. То есть сотрудники подключаются в крайних случаях, все типовые операции выполняет система — как по обработке, так и по принятию решений. Соответственно запросы клиентов обрабатываются быстрее.
• Минимизируется человеческий фактор. Менеджерам компаний просто надоедает управлять толпой народа. К людям нужно находить подход, они устают, болеют, бывают в плохом настроении. И в итоге руководство хочет заменить их системой. Наверное, половина наших проектов стартует именно с таким запросом.

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

*Индекс NPS (англ. Net Promoter Score) — индекс определения приверженности потребителей товару или компании (индекс готовности рекомендовать), используется для оценки готовности к повторным покупкам. Является одним из главных индексов измерения клиентской лояльности.

Больше информации о технологиях, клиентском сервисе, автоматизации вы найдете на нашем сайте, в Telegram-канале и на нашей странице в Facebook

Источник: vc.ru

Что такое клиент-серверный и файловый режим?

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

Что такое клиент-серверный режим?

Работу сотрудников компании с 1С можно организовать в нескольких режимах, один из которых — «клиент-серверный». Если вам необходимо увеличить скорость работы системы 1С, улучшить её производительность и надёжность, то клиент-серверный режим однозначно подойдёт.

Он реализован на основе трехуровневой архитектуры «клиент-сервер»: клиентское приложение (то есть программа, с которой работают сотрудники компании) — кластер серверов 1С Предприятия — сервер с базами данных. Все наглядно показано на схеме.

Клиент-серверный вариант работы 1С предназначен для использования в отделах, рабочих группах или в масштабе средних и крупных компаний с количеством пользователей 5 и более. А если вы используете конфигурацию 1С на основе управляемых форм ( Управление торговлей 11, Управление нашей фирмой 8, Документооборот 8, Бухгалтерия предприятия 3.0, Розница 2.0), то клиент-серверный режим желателен даже от 3 пользователей, ведь нагрузка выше.

Использование клиент-серверного варианта работы с 1С Предприятия 8.2 позволяет выполнять объемные операции по обработке данных. Даже при очень сложных запросах, программа, работающая у пользователя (клиент), будет получать только необходимую ей информацию, а вся обработка будет выполняться на сервере. В клиент-серверном варианте информационная база хранится в одной из поддерживаемых СУБД: Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database. К ней по мере необходимости обращается клиентское приложение через кластер серверов 1С Предприятие.

Почему выгодно работать в клиент-серверном режиме?

1. Распределяется нагрузка между серверами, а значит работа пользователей становится комфортнее, быстрее и эффективнее.
2. Данные защищены от сбоев в компьютерах ваших сотрудников и локальной сети. Даже если менеджеру пришел в письме вирус — шифровальщик и он его открыл — ничего страшного, ваши данные уцелеют и работа продолжится.
3. Оптимально для крупных производственных компаний. Ведь чем больше нагрузка на базу 1С в компании, тем большие мощности ей требуются, тем чаще тормозит система, тем больше рабочего времени тратят сотрудники на устранение проблемы, вместо своей работы. Клиент-серверный режим спасает ситуацию.
4. Одновременно могут комфортно работать большое количество пользователей.
5. Все конфиденциально (сотрудник компании контактирует с базой исключительно через сервер).
6. Можно вести большие БД (более 2Гб).
7. Удобно администрировать.
8. Система отказоустойчивая (в случае необходимости переключается на другой сервер).
9. Регламентные задания работают без пользователей
10. Снижение затрат. Ваши IT — специалисты будут решать стратегические бизнес-задачи вместо «тушения пожаров» из-за остановившейся работы базы 1С, а это значит, что выгода от использование клиент-серверного режима работы равна как минимум стоимости одного системного администратора в месяц.

Начинайте работать эффективнее уже сейчас! Оставьте заявку на перевод работы в клиент-серверный режим и больше не переживайте за безопасность данных и скорость работы сотрудников. Тестовый период абсолютно бесплатно.

Файловый режим

Файловый вариант работы 1С предназначен для работы одного или нескольких пользователей в локальной сети. При этом все данные информационной базы (конфигурация, база данных, административная информация) располагаются в одном файле — файловой базе данных, разработанной специально для прикладных решений 1С Предприятия 8.

Сравним достоинства и недостатки файлового режима:

1. Оптимален для небольшого количества пользователей (до 5-ти)
2. Просто установить и использовать
3. Для работы с информационной базой не требуются дополнительные программные средства кроме операционной системы и 1С Предприятие
4. Простое создание резервных копий путем простого копирования файла информационной базы
5. Снижен риск нарушения целостности данных при сбоях компьютеров и локальной сети
6. Невысокая стоимость

1. Размер базы до 10 ГБ в одной таблице
2. Менее надёжная чем клиент-серверный вариант
3. Без активных пользователей не работают регламентные задания
4. Нет отказоустойчивости. База 1С — это папка в сети, любое повреждение файлов в этой папке по сети может повредить информационную базу.

Подведем итоги

Файловые информационные базы комфортны для работы 1-3 пользователей. И то при условии, что объемы данных сравнительно небольшие. Если в вашей компании больше сотрудников и данных — выбирайте клиент-серверный режим.

Даже для маленьких компаний в линейке программ 1С, есть, например, бюджетный Сервер МИНИ на 5 подключений, он стоит 14400 рублей. А экономит, как мы уже разобрались выше — зарплату целого системного администратора.

Если же пользователей в онлайне больше 5, то тут вам нужна Лицензия на сервер и соответствующее количеству пользователей Клиентская лицензия на рабочие места. Лицензия на сервер нужна, чтобы работал программа-сервер 1С, а количество клиентских лицензий должно соответствовать подключающимся пользователям (сеансам).

Примеры финансовых затрат на подключение клиент-серверного режима

* При увеличении количества рабочих мест Вы можете сделать апгрейд с 1С:Предприятие.Сервер МИНИ на 5 подключений на 1С:Предприятие 8.3. Лицензия на сервер 64 bit.

Как установить клиент-серверный режим?

1. Приобрести лицензионную ПО для Сервера «1С:Предприятие»
2. Определить подходящую СУБД:
   — есть не требующие оплаты, но с ограничениями (PostgreSQL)
   — лицензированный вариант и доступ клиента MS SQL
3. Произвести настройку установленной базы под программу. Также должна быть учтена необходимость в сохранении резервных копий, планировании оптимизации
4. Выполнить установку и наладку «1С:Сервер», включая функцию администрирования.

Остались вопросы? Оставьте заявку на бесплатную консультацию прямо сейчас.

Источник: tu-don.ru