Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Автоматизация бизнес-процессов

Как отличать объекты друг от друга и при чем тут хэш-функции

30.03.2021 10:05:43 | Автор: admin
Привет! Я возглавляю направление R&D в компании ЛАНИТ Би Пи Эм, которая специализируется на автоматизации бизнес-процессов. Мы исследуем тренды, готовим образовательные программы для технических сотрудников, ведем собственную продуктовую разработку. Наши наработки успешно используются в нескольких компаниях-заказчиках.

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

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

Источник

Какими бывают подходы к идентификации данных


Генерация идентификаторов


Первый подход, который мы рассмотрим, когда идентификатор генерируется и приписывается к объекту.

При этом важны:

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

Наиболее распространённые реализации:


Как выглядит UUID (uuidtools.com)

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

Подробнее можно почитать здесь:


Вычисление идентификаторов


Второй подход вместо генерации вычислять идентификатор на основе данных объекта. Это применимо в случаях, когда идентичность всех данных объектов означает и идентичность объектов, т. е. в системе не может / не должно быть двух разных объектов с полностью одинаковыми данными. Чаще всего вычисление идентификатора делается путём хеширования (hash / digest) свёртывания данных объекта, обычно в число фиксированной разрядности.

Для хеширования важны:

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

Популярные реализации:


Криптоустойчивые реализации:


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

Источник. Вычисление хеша

Сценарии


Репликация сущностей между БД


В распределённой архитектуре несколько систем со своими БД порождают сущности, которые реплицируются между БД. Идентификаторы сущностей должны быть уникальными в масштабах всей архитектуры.

Пример решения: использовать в качестве идентификатора UUID или Snowflake ID.

Дедупликация событий


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

Пример решения: система-производитель генерирует UUID для каждого события, каждая система-потребитель индивидуально ведёт в своей БД учёт обработанных идентификаторов. Поскольку идентификаторы глобальные, созданные в разных системах идентификаторы будут уникальными.

Быстрый поиск объектов


Имеется большой список объектов, и необходимо ускорить поиск объекта по заданным атрибутам.

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

Источник. Хеш-таблица

Детали реализации хеш-таблиц в Java:


Контроль целостности файлов


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

Пример решения: публиковать хеш рядом с файлом, вычислять на клиенте хеш скачанного файла и сравнивать со скачанным хешем (контрольной суммой).

Источник. Вычисление контрольной суммы

Безопасное хранение паролей


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

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

Компактный производный идентификатор


Git является распределённым и децентрализованным репозиторием, при этом необходимо уникально идентифицировать каждое изменение (commit).

Пример решения: использовать полную информацию об изменении (файлы, дата изменения, автор, идентификатор предыдущего изменения) для расчёта хеша, который будет идентификатором. Использовать криптоустойчивую хеш-функцию, чтобы исключить совпадение идентификаторов и подлог изменений в публичных репозиториях.

Источник. Идентификаторы в Git

Объект электронной подписи


Необходимо подписать документ электронной подписью, при этом алгоритм электронной подписи не может работать с большим объёмом данных или работает медленно.

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

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

Заключение


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

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

Приходите к нам работать!

Подробнее..
Категории: Информационная безопасность , Блог компании гк ланит , Ланит , Автоматизация бизнес-процессов , Идентификация , Ланит - би пи эм

Автоматизация бизнеса начинаем разбираться

28.09.2020 14:11:21 | Автор: admin
Помните старый мультфильм про Нехочуху? Ленивый мальчишка попал в страну великого Нехочухи, где большинство действий выполняли роботы. Надо сказать, мультипликаторы изобразили безрадостную картину автоматизации: человек внутри роботизированных процессов распадается как личность и теряет навыки социальной адаптации. Это идёт явно вразрез с любимым нами Электроником, который как раз проповедует ценность соединения автоматизации и человеческого начала. Что-то нас в философию занесло.

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


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

Определения автоматизации не существует?


Если вы попробуете найти определение автоматизации бизнеса в интернете, то встретите разные варианты, связанные с контролем, с роботизацией, с искусственным интеллектом и т.д. Ни одно из них не будет исчерпывающим и точным. Давайте попробуем дать определение здесь, на Хабре.

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

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

В теории, в идеальном мире автоматизация бизнеса и автоматизация бизнес-процессов равнозначные понятия, потому что в бизнесе всё есть процесс, который можно дискретизировать, разложить на подпроцессы и этапы и описать. Но в реальном мире в компаниях есть масса активностей, не попадающих под определение бизнес-процесса, сами процессы неоптимизированы или отсутствуют вовсе, а вся работа ведётся стихийно. Поэтому в задачи автоматизации неожиданно попадает огромный подготовительный этап, в коде которого нужно проанализировать, описать и подготовить бизнес-процессы.
Мы приняли решение: для всех, кто пришёл с Хабра и оставил заявку в форме, бесплатный анализ бизнес-процессов компании будет доступен всегда. Это работа наших экспертов, связанная с анализом вашего бизнеса с последующей выработкой рекомендаций и обычно она стоит от 15 000 рублей, но нам для науки хвоста не жалко Хабра ничего не жалко. Записывайтесь, мы с вами свяжемся, назначим время (это займёт далеко не 15 минут) и обсудим бизнес-процессы вашей компании или проблемы с бизнес-процессами. Общение с экспертом не накладывает на вас никаких обязательств.

Какой бизнес нужно автоматизировать?


Любой.

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

  • Экономия одна из ключевых целей автоматизации. Вложившись в программное обеспечение, компании используют его либо для увеличения производительности труда, либо для сокращения затрат. Таким образом, компания как минимум экономит время и деньги на изменении структуры сделок и продаж, увеличивая при этом оборот и прибыль. Чтобы автоматизация оказалась откровенно убыточной, нужно просто забросить купленную программу и забыть о потраченных деньгах.
  • Упорядочить и ускорить бизнес-процессы ключевая задача автоматизации. Сокращение времени на каждую операцию, определение чётких этапов, ответственных и сроков делает процесс эффективным, прозрачным и отлаженным. Чёткое распределение задач между сотрудниками минимизирует человеческий фактор и сокращает связанные с ним риски.
  • Увеличение прозрачности бизнеса в целом важная цель. Автоматизация помогает сотрудникам работать с клиентами и друг с другом в единой информационной системе и не конфликтовать на переделе клиентов и следовать индивидуальным KPI; клиентам получать своевременное и качественное обслуживание; руководителю видеть реальные результаты работы сотрудников. Такая прозрачность не только формирует позиционирование компании, но и ведёт к росту выручки благодаря исключению конфликтов и лояльности клиентов, а также стандартизации процессов (стандартный, фиксированный бизнес-процесс признак надёжной компании).

Что можно автоматизировать в бизнесе?


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

А вот остальные процессы можно вполне автоматизировать. Как мы уже упомянули, есть три основных группы бизнес-процессов.

Группа процессов

Вид и особенности автоматизации
Управляющие бизнес-процессы, которые включены в стратегический менеджмент и управление организацией. CRM, ERP, системы управления проектами, аналитические системы. Рабочее место руководителя предполагает полный доступ к данным компании, расширенную аналитику, возможности делегирования и перераспределения задач.
Операционные процессы совокупность процессов, составляющих основную деятельность компании. Это как раз то, что мы с вами делаем на работе: производство, разработка, маркетинг, продажи, поддержка и т.д. CRM, ERP, системы управления проектами, ECM, WMS, САПР, АСТПП и прочие специализированные системы. Должны быть либо универсальными (все подразделения в одной информационной системе), либо интегрированными между собой.
Поддерживающие процессы процессы, которые решают внутренние задачи организации: системное администрирование, ITSM, бухгалтерский учёт, логистика и т.д. Специализированное ПО, которое может быть интегрировано с предыдущей группой или работать самостоятельно (1С, тикет-системы, логистические маршрутные системы, М2М и т.д.)
Упомянутые активности с высоким человеческим фактором. Программы для управления и подбора персонала, корпоративные порталы, чаты, мессенджеры и т.д. Те программы, которые облегчают работу, геймифицируют процессы, унифицируют коммуникацию, но при этом не исключают человеческий фактор в тех процессах, где он решающий.

Что даёт автоматизация бизнесу?


В любом бизнесе сейчас собирается много данных и они открывают интересные перспективы для работы с клиентами: можно совершать допродажи, сегментировать, планировать акции, менять ассортимент и проч. Более того, любое решение, принятое по наитию, без анализа качественных и количественных показателей, скорее всего обернётся провалом. Собирать данные вручную, в Excel или Access тяжёлый и неблагодарный труд, поскольку такую информацию легко потерять или повредить, а организована она как правило из рук вон плохо. Автоматизация помогает собирать данные в базах данных, а СУБД надёжно хранит данные и позволяет интерпретировать их и строить сложные срезы. Кроме того, хранение информации в БД несравнимо безопаснее: права доступа, резервное копирование, аппаратная защита позволяют всей коммерческой и производственной информации храниться максимально надёжно.


Это вообще про весь российский бизнес. Только большинство пока на стадии отрицания

Автоматизация упорядочивает, налаживает оперативную работу и управление задачами. Все сотрудники (причём совершенно не важно, удалённые или офисные) работают в едином информационном пространстве АСУ (PM, ERP, CRM), координируют свои действия, получают и делегируют задачи, видят свои задания внутри проектов и бизнес-процессов, распределяют свою нагрузку во времени. Руководителю больше не нужно вызывать каждого к себе и разжёвывать задачи достаточно поставить их в системе и проконтролировать выполнение. Вся оперативная работа ведётся в единой системе и любой сотрудник может получить доступ к данным в рамках своих компетенций, а также запросить доступ или выгрузку данных, если в этом есть необходимость. Вне автоматизации всё это представляет собой сплошную стихийную коммуникацию, в которой несложно забыть, ошибиться или просто незаметно не выполнить задачу.

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

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

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

Прежде всего нужно выбрать правильные процессы для автоматизации:

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

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

Как измерить эффективность автоматизации?


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

Если говорить чисто экспертно, то для компаний без риска банкротства и прочих финансовых проблем принято считать срок окупаемости систем автоматизации так: оптимистичный сценарий 1 года, реалистичный сценарий 2 года, пессимистичный от 3 лет. Однако это весьма усреднённый показатель, поскольку у компаний разный оборот, разные цели автоматизации, разная стоимость самого ПО. Поэтому лучше подумать о показателях и результатах внедрения системы автоматизации заранее.

Что может стать показателем эффективности внедрения системы автоматизации в малом и среднем бизнесе:

  • время, затрачиваемое на операцию или процесс если в результате автоматизации оно сократилось, значит, всё сделано правильно;
  • продолжительность сделки: она может не измениться, но сокращение цикла сделки и цикла продаж очевидно хороший знак;
  • метрики KPI отличный инструмент для измерения эффективности автоматизации: сравнивая показатели сотрудников в динамике, можно увидеть, как они изменились и по вектору изменений судить о результатах или принимать меры для корректировки работы сотрудников в АСУ (например, в CRM);
  • количество жалоб или обращений в службу поддержки после внедрения автоматизации поток жалоб должен сократиться за счёт того что менеджеры не будут допускать части ошибок в работе с клиентами (таких как простроченные контакты, забытые письма и документы, пропущенные звонки и т.д.).

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

Один из рабочих методов оценивать по стоимости бизнес-процесса или трудозатратам каждого сотрудника. Рассмотрим на примере.

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

Менеджер Вася тратит на всю эту цепочку примерно 8 рабочих дней, но не целиком, а в среднем по 2 часа в день (встреча длиннее, звонок короче и т.д.). Итого Вася потратил 16 часов на этого клиента. Из них самые длинные этапы: встреча (ничего не поделаешь, её не учитываем), подсчёт товара на складе и общение с логистом (2 часа), подготовка КП (1 час), подготовка договора (2 часа), подготовка закрывающих документов (1 час). Итого 6 часов оперативной работы с документами и складом. Час работы Васи обходится работодателю в 400 рублей (чистые васины + налоги и соцстрах), то есть эта вот работа 2400 рублей. Не очень много, если учесть, что заказ будет большим. Пусть наш Вася больше ничего в компании не делает, только флешки с нанесением продаёт корпам, значит, за месяц он может обслужить 10 клиентов. То есть оперативная работа Васи обойдётся в 24 000, в год 264 000 (1 месяц он в отпуске).

А теперь представим, что в компании есть CRM, в которой отображаются остатки на складе в режиме реального времени, включены шаблоны КП и договоров, есть печатные формы всей закрывающей документации. Васе не нужно перепечатывать и копипастить наименования, считать цены и стоимость, искать скидки, вбивать реквизиты, искать логиста и перебирать виды флешек по коробочкам он всё это видит в CRM и заполняет документы в 10-20 кликов, выбирая точные наименования, условия скидок, услуги и т.д., отсылая всё это из почты в CRM клиенту. При самой низкой сноровке он потратит 1 час, то есть в 6 раз меньше. И компании в год его оперативная возня обойдётся в 44 000? Нет, больше потому что Вася сможет обслужить гораздо больше клиентов. То есть накладные расходы на сделку сократятся, а количество сделок вырастет. В масштабах даже небольшого рекламного агентства это прямо норм.

Смоделируем: рынок конкурентный, не безграничный и Вася смог обслужить в среднем в месяц по 15 клиентов. По старой схеме компания бы за его рутину заплатила 396 000 рублей (11 месяцев * 15 клиентов * 2400 рублей). По новой схеме с CRM 66 000 рублей. При этом 1 лицензия CRM на Васю стоила примерно 16 000 рублей навсегда, без аренды (представим, что компания купила единоразово 10 лицензий RegionSoft CRM Professional Plus). То есть чисто экономия на части процесса (на малой части!) уже окупает лицензию сотрудника. А ведь ещё и автоматизирован дорогой логист, склад и проч. То есть стоимость бизнес-процесса благодаря автоматизации становится ниже. А мы с вами ещё не посчитали увеличение дохода за счёт прибывших клиентов, на которых у Васи стало хватать времени.
А теперь вернёмся к вопросу экономического эффекта от внедрения системы автоматизации. Можно провести расчёт для каждого этапа всех процессов в компании и каждого задействованного сотрудника в конечном итоге получится примерный эффект. Только не забывайте, что для оценки стоимости владения системой вам понадобится рассчитать интегральный показатель совокупной стоимости владения (Total Cost of Ownership, TCO), который включает затраты, связанные с приобретением, внедрением и эксплуатацией АСУ; а стоимость сотрудника и часа его работы следует рассчитывать не по чистой заработной плате, а по ФОТу, социальным затратам, косвенным затратам (оргтехника, содержание офиса, интернет и т.д.)

Не забывайте, что ТСО для облачных систем нужно умножать на количество используемых месяцев и он будет постоянно расти за счёт периодических платежей, а для десктопных систем ТСО чаще состоит из единовременного платежа за лицензии (ну или рассрочки), стоимости доработки, поддержки и обновлений. Иногда компании выгоднее иметь ТСО хоть и больше, но распределённым во времени для таких компаний мы, например, и для десктопной RegionSoft CRM предлагаем аренду с возможностью выкупа ПО после 7 месяцев аренды и кучей других бонусов.

Кстати, о CRM.

Средства автоматизации бизнеса


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

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

Как выбрать средство автоматизации?


Есть два основных пути выбрать систему автоматизации бизнеса.

  1. Приобрести готовое решение у вендора (разработчика) и провести профессиональное внедрение. В конечном итоге это быстрее, дешевле и легче: на рынке представлено такое количество решений, что можно найти что угодно, от систем автоматизации автосервиса, систем автоматизации учебных курсов и салонов красоты до крупных решений автоматизации завода. Вы выиграете по срокам, точности внедрения, корректности обучения и сможете довольно быстро приступить к работе в новой плоскости.
  2. Разработать систему самостоятельно и самостоятельно же внедрить. По состоянию на 2020 год это, конечно, путь самурая и не факт, что в конце не будет харакири. Долгий, сложный процесс с подбором стека технологий и исполнителей, затянутыми сроками, откровенными кидками от нанятых разработчиков и т.д. Сложно придумать сферу, которой бы подошёл этот вариант. Разве что вы форкнете какой-нибудь опенсорс, сделаете кастомную отраслевую версию и решите стать ИТ-компанией, внедряющей этот софт. Это куда ни шло. А трата времени на собственную разработку, когда вокруг есть всё, сильно смахивает на потребность собрать себе своими руками автомобиль из холодильника Саратов и движка от Феррари по фану, круто, но безумно дорого и проблематично в эксплуатации.

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

CRM как частный случай автоматизации бизнеса


CRM-система один из самых популярных инструментов автоматизации малого и среднего бизнеса. И если раньше CRM-система автоматизировала только отдел продаж и немножечко маркетинг, то сейчас большинство современных решений на рынке представляют собой универсальные бизнес-комбайны. Например, наша редакция RegionSoft CRM Enterprise Plus уже фактически полноценная ERP и может в одной программе: автоматизировать продажи, управление проектами, задачами, KPI, работу с первичными документами, включает в себя почту, телефонию, мультивалютный учёт, логистику, складской учёт, кассовый учёт, многопередельное производство, механизм расчётов, имеет более 100 типовых отчётов, различные конструкторы и, конечно, механизм автоматизации бизнес-процессов. А кроме этого, раз в 2-3 года выходят мажорные релизы, которые добавляют самые востребованные функции к уже существующим. Вся эта история называется сквозной автоматизацией самым безопасным и удобным способом автоматизации, когда практически вся компания может работать в одной информационной среде.

CRM-система на сегодняшний день это базовый элемент автоматизации, понятный и остро необходимый, особенно в кризис, особенно для распределённой команды. Да что там говорить необходимый всегда!

Однако, выбирая CRM, как и любое другое средство автоматизации, нужно помнить о трёх главных правилах:

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

По разным оценкам экспертов, уровень автоматизации российских компаний составляет где-то от 10 до 15%. Это очень мало. Да и своими глазами мы можем видеть, как, например, доставка Перекрёстка приезжает при терминалах, чековых машинах, всё отлажено и работает как часы, а ресторан в центре города только недавно перестал выдавать рукописные чеки, бронь так до сих пор записана на меловой доске; как небольшие ИТ-компании вкладываются в автоматизацию всего и вся, чтобы быть впереди, а серьёзные торговые компании вручную заполняют счета и акты Эти перекосы обусловлены и национальными особенностями, и недоверием к технологиям, и переживаниям за себя в пространстве отечественной экономики. Но факт остаётся фактом: с автоматизированным бизнесом живётся гораздо лучше, безопаснее и устойчивее. Всё остальное надуманные оправдания.

У нас действует акция Осень вступает в свои права вы можете купить RegionSoft CRM на очень хороших условиях:

  1. Для тех, кто покупает сразу (100% предоплата) предоставляется скидка в размере 15% от цены стандартного прайс-листа.
  2. Для тех, кто покупает в рассрочку- беспроцентная рассрочка на 3 равных платежа, по 1 платежу в месяц, при условии совокупной стоимости лицензий от 38 000 руб.
  3. Подписка вместо покупки предоставляется скидка в размере 30% при оплате подписки на 3 месяца. Минимальная стоимость подписки составляет 3400 рублей в месяц (без учёта скидки).

А ещё мы здорово работаем удалённо: устанавливаем, внедряем, обучаем, поддерживаем. Звоните или оставляйте заявку онлайн-демонстрация бесплатная, подробная и интересная.


Мультик про Нехочуху, если вы вдруг не олд и не бумер:

Подробнее..
Категории: It-инфраструктура , Автоматизация , Софт , Блог компании regionsoft developer studio , Crm-системы , Erp-системы , Автоматизация бизнеса , Автоматизация бизнес-процессов

Поздравляю, вы изобрели белую маркерную доску

24.11.2020 16:19:42 | Автор: admin

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

Видите доску?Видите доску?

На заре моей карьеры в среднего размера технологической компании был забавный руководитель отдела продаж: он не очень смыслил в продажах и расчётах, но ужасно любил всякую красоту на рабочем месте. Раскрашенные всеми цветами таблички Excel, презентации к каждому совещанию (даже если там три строчки), проклеенная цветными стикерами тетрадь-блокнот В общем, то ли медитировал, то ли имитировал. Однажды у нас остался огромный прошлогодний календарь формата А0 с толстенными листами и белыми обратками месяцев. Он повесил его картинками к стене и мы начали на нём писать задачи и расчёты исключительно карандашом. Каждый вечер наш коллега тщательно стирал неактуальное и утром мы писали что-то новое. Постепенно у нас образовалось что-то типа скрама (тогда это слово было не в моде, мы все были старыми и юными любителями водопадной модели). Однажды к нам зашёл генеральный и во время своей пламенной речи упорно разглядывал этот календарь. В конце разноса нашего боевого отдела он спросил, что это. Вот рисуем, стираем, очень удобно. Сам изобрёл, счастливо просиял рационализатор. Через два дня пришёл завхоз и повесил нам маркерную доску с пятью маркерами и губкой-стиралкой. По распоряжению свыше.

Рационализатор облюбовал доску (мы потом на ней ещё диаграмму Гантта изобрели, три буквы написали и много чего интересного), но грустил: всё придумано до нас. Я в числе остальных посмеивалась над его изобретательскими талантами и будучи человеком, ответственным за расчётную и аналитическую работу, а также выплаты партнёрам, рисовала в Excel нечто: листы-странички по каждому региону, отдельный лист с планами и фактами, лист с импортом план-фактов из отчётов плюс сводные листы и полные расшифровки выплат, которые я таскала вручную из СУБД (макросы и VBA-код появились в жизни этого файла чуть позже). Это был 2009 год, я ещё не знала, что такое CRM и что буквально спустя 2 года я возглавлю одну из групп внедрения SAP, а 4 года спустя работа в/с/для RegionSoft CRM окончательно убедит меня в несостоятельности всех моих потуг в Excel и Access. Но это меня.

Часто приходится видеть, как сотрудники компаний изобретают то, что уже есть примерно вот так:

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

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

Этап 2. Работа нарастает, занимает всё больше времени, данные разрастаются и либо удаляются, либо создают путаницу. Возникают неприятные инциденты, такие как поиск старых данных, постоянные перезапросы одного и того же у коллег (например, просьба выгрузить продажи за март в июне, потом в августе, потом в декабре), поиск нужной информации по папкам рабочего ПК и почты. Становится нервно и дискомфортно.

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

Этап 4. Идея распространяется на коллег. Создаются совместные файлы.

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

В зарубежных изданиях и в сервисах вопросов можно найти такие запросы: Как уговорить руководителя внедрить CRM? или Аргументы за внедрение CRM для босса (из того, что запомнилось почти дословно convincing your boss you need CRM software). Представить такую историю в российской компании практически невозможно. Потому что:

  • никто из сотрудников не готов нести ответственность за процесс внедрения и покупку дорогостоящего программного обеспечения;

  • сотрудники считают, что СRM их заменит и приведёт к увольнениям (если что, это миф, система работает только вкупе с человеческим мозгом, руками и языком, иначе пока никак);

  • мало кто верит в возможности автоматизации;

  • до сих пор многие сотрудники (даже молодые) с компьютером даже не на вы, а на кто вы;

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

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

Работа идёт значительно медленнее. Любая адекватная CRM-система на рынке устроена так, что данные вы можете выбрать одним кликом и использовать их для отправки в чат, на почту или для звонка. Это уже значительно облегчает и ускоряет работу. В продвинутых же CRM-системах можно создавать шаблоны любых документов и сотрудники легко создают комплекты для каждого клиента в несколько кликов и за считанные минуты. И им это реально нравится, потому что быстро и удобно, рутинная работа больше не давит (сотрудники, работающие в CRM, вообще обожают эту фишку с автоматическим формированием документов, для них это магия ну и действительно, зачем им знать о механизмах дизайнера отчётов?).

Я однажды провела эксперимент. Взяла реальный пакет документов инженера обслуживания АЗС и набрала их руками в формах государственного образца (акт + счёт + счёт-фактура + договор подряда), а затем создала клиента, услуги и шаблон договора подряда в нашей RegionSoft CRM и оформила тот же пакет документов. Вручную эта история заняла 1 час 10 минут, в CRM чуть менее 15 минут с проверкой и выводом на печать. Да, время заняла настройка шаблонов и ввод данных, но эта работа делается один раз, а пакет документов формируется ежемесячно. У одного инженера 10-15 клиентов, инженеров трое, менеджер у них один. Итого 36 часов в год против 168 часов, свободное время менеджера можно перераспределить на поиск новых клиентов, контроль качества и любые другие задачи.

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

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

Всё в той же компании произошёл такой инцидент: в сетевой папке лежал общий файл со списком дилеров с полями дилер, счёт дилера, ID дилера, суммарные выплаты за всё время, сумма к начислению. Суммы к начислению заносились в конце месяца вручную и бухгалтер забирала данные для перечисления средств. После расчёта с дилерами стали поступать жалобы на ошибочные выплаты а это свыше 100 агентов. Ошибочными оказались все выплаты. Причина оказалась банальной: новая сотрудница отсортировала столбец с наименованием дилера, но забыла отсортировать весь массив, а точнее, не знала, что это так делается. Итог: несколько дней переработок трёх сотрудников для доначисления и вычета сумм, подготовки новых документов, извиняющихся писем и т.д. Это, кстати, был последний пинок перед стартом процесса выбора и внедрения CRM.

Когда данные хранятся в СУБД, сломать их на клиенте практически нереально (а если и реально, есть бэкап). Сотрудник работает в интерфейсе своей рабочей программы и данные отображаются, но при этом не меняют своих позиций и значений в таблицах. Изменить значения могут сотрудники с определёнными правами доступа, таким образом можно защитить информацию и одновременно позволить всем сотрудникам иметь доступ к работе с данными для аналитики или работы с клиентами.

У компании нет клиентской базы. Клиентская база нужна каждой компании, а не только ритейлу и сфере услуг, как это иногда кажется. Для каждой компании вашей, нашей, любой на Хабре клиент это один из основных источников денег, которые идут на зарплату, закупку оборудования, средства разработки и т.д. Разрозненные списки клиентов у каждого менеджера это не клиентская база, точно также ею не являются все эти таблицы и файлы с информацией об объёме продаж. Клиентская база это упорядоченная совокупность данных о клиентах, сделках, документах и значимых событиях и воздействиях. Именно она лежит в основе успешной рекламы, хороших продаж и допродаж. Это второй ценный актив в компании после её сотрудников. Задача автоматизированных средств управления бизнесом и в частности CRM-систем сбор, сохранение и анализ этого актива, формирование клиентской базы.

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

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

Работа с CRM-системой решает эти проблемы. Как было уже сказано выше, каждый сотрудник имеет свои права доступа к системе, дополнительно данные защищает резервное копирование, вся собранная информация хранится либо на вашем внутреннем сервере, либо у надёжного хостера VDS. Внутри CRM-системы ведётся переписка с клиентами, в ней же формируются и хранятся документы и записи переговоров. Чтобы всё это достать, мошеннику или злонамеренному правонарушителю понадобится получить доступ уже не к личной почте сотрудника, а к корпоративной CRM-системе и он рискует либо не справиться вовсе, либо оказаться замеченным и опять же не достичь цели. Бизнес ПО это всегда защищённая среда, которая предохраняет от большинства популярных способов проникновения в IT-среду с данными. Как правило, малому бизнесу этого хватает с головой. А если ваши коммерческие данные сверхценные и вы точно знаете, что охота на них далеко не случайный акт, вы всегда можете попросить вендора о дополнительных средствах защиты информации у всех опытных разработчиков CRM непременно найдутся дополнительные возможности безопасности (правда, чаще за деньги).

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

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

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

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

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

Если вы всё же решились на автоматизацию, всё просто: как бы ни уволился сотрудник, его работа всегда сохранена в CRM-системе и может быть мгновенно делегирована другому сотруднику.

Вот такие простые, обидные и уносящие прибыль последствия есть у компаний, которые не готовы дать сотрудникам самый простой рабочий инструмент. Остаётся вопрос: так а зачем им тогда компьютеры на рабочих местах? Ведь для почты можно оставить 1-2 компьютера, на них же поставить офисный пакет для оформления документов Заодно не будут на ютубчике и в интернет-магазинах рабочий день просиживать. Надеюсь, я не подала никому идею? Если что, это был сарказм.

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

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

Подробнее..
Категории: It-инфраструктура , Управление персоналом , Софт , Блог компании regionsoft developer studio , Crm-системы , Crm , Автоматизация бизнеса , Автоматизация бизнес-процессов

Recovery mode Автоматизация взаимодействия дилеров и отдела продаж в крупном предприятии

01.10.2020 18:11:51 | Автор: admin

Проектирование автоматизированной системы работы с дилерами





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

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

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

Конечно, добавим, ответим мы и обязательно предложим сделать это правильно.

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

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

  • Что будет в личном кабинете дилера?
  • Просто заказы с документами и создание нового.

  • Действительно, просто. А откуда возьмутся заказы? Как сейчас они создаются? Возможно ли взаимодействие с этой системой через api? Кто сможет их создавать в нашей системе? А кто не сможет? Можно ли отменить? А если заказ уже отгружен? У кого будет доступ к заказу? А документы в какой момент и откуда возьмутся? А можно ли их выгрузить? Как будут меняться статусы? Будет ли кто-то контролировать выполнение заказа? С заказом могут быть рекламные материалы, говорите? А что за материалы, кто их создает, кто прикрепляет к заказу?

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

Исследование


Исследование предметной области

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

Наш клиент один из ведущих российских производителей материалов для строительства и отделки. Это предприятие полного цикла производства: от добычи гипсового камня (у компании собственная сырьевая база) до фасовки и упаковки готовой продукции. Поставки продукции компании осуществляются в более чем 100 городов России, а также в другие страны Европы и Азии. У компании примерно 150 дилеров, которые реализуют продукцию своей оптово-розничной сети. Ведется тщательная работа по привлечению и удержанию дилеров. Компания всячески поддерживает их в продвижении товаров, стимулирует продавать больше интересными маркетинговыми акциями и системой бонусов.

Интервью с заинтересованными лицами, постановка бизнес-целей

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



Такие проблемы нам были озвучены:

  • Вся работа с дилерами ведется по телефону и электронной почте. Заказ оформляется письмом на электронный адрес, обновления по нему обсуждаются в личном общении. Общение и оформление заказа ручной труд, который отнимает много времени сотрудников.
  • Нет актуальной информации о наличии товара на складе. Информация об остатках поступает менеджерам утром и не обновляется в течение дня. При формировании заказа нельзя точно сказать, доступно ли нужное количество товара.
  • У компании нет данных о деятельности дилеров: количестве товара на их складе, доле продукции компании в общем портфеле, популярности конкретных линеек товара, конечных покупателях и потребителях. Таким образом, нет возможности оптимально планировать отгрузки и маркетинговую деятельность.
  • Дилеры не получают полную информацию о сотрудничестве с компанией, теряют документы, не понимают, насколько выполнен план продаж, не знают о положенных им бонусах и подарках.
  • Анализ объемов продаж дилерам, остатки на их складах, планирование производства происходит в ручном виде аналитиком предприятия на основе догадок и предположений. Все данные собираются в один файл в формате excel, из него создаются отчеты.
  • Руководители отдела не получают точной информации о работе сотрудников своего отдела и не могут точно планировать их загрузку, ставить планы продаж.

Таким образом, целями работы стали:

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

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

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

На первой встрече с нашим заказчиком мы также:

1. Узнали, что:

  • Все продажи компании организованы по дивизионам, созданным с географической привязкой к странам и регионам России.
  • У каждого дивизиона есть руководитель и несколько региональных менеджеров, за которыми закреплены регионы и торговые представители (дилеры) в конкретных городах.
  • Дилеры, в свою очередь, продают продукцию компании своей оптовой и розничной сети, поставляют на стройки объектов.

2. Получили:

  • Договор партнерства,
  • Пример аналитического отчета об отгрузках,
  • Каталог продукции,
  • Рекламные материалы.

3. Познакомились с:

  • Генеральным директором,
  • Коммерческим директором,
  • Руководителем отдела продаж,
  • Руководителем отдела маркетинга.,
  • Руководителем отдела логистики,
  • Главным бухгалтером.

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

а) пригласить на встречу заинтересованных в создании системы руководителей высшего звена и тех сотрудников, кто создает и участвует в автоматизируемых бизнес-процессах. Участников не должно быть много, достаточно 5-6 человек, со всеми остальными мы обязательно поговорим позже. Общение с каждым не займет много времени, пока нам важно, чтобы сотрудник был в курсе проекта, дал свои координаты для оперативной связи, был готов участвовать в работе по исследованию бизнес-процессов;

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

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

AS IS или описание существующих бизнес-процессов, выявление проблем, сбор пользовательских требований


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

Пример списка сотрудников для общения:

  • Генеральный директор;
  • Заместители директора (два человека);
  • Руководитель дивизиона (три человека);
  • Менеджер отдела продаж (три человека);
  • Руководитель отдела логистики;
  • Руководитель отдела маркетинга;
  • Главный бухгалтер;
  • Трейд-маркетолог;
  • Аналитик;
  • Дилер (три человека).

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

Пример описания текущей ситуации:

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

Для размещения заказа дилер отправляет письмо-заявку на электронный адрес закрепленного за компанией менеджера. В заявке он указывает:

1. Названия и количество товаров, которые необходимы,
2. Свои реквизиты;
3. Адрес грузополучателя, куда необходимо отгрузить товар;
4. Транспорт, которым необходимо отправить товар;
5. Желаемую дату отгрузки.

Менеджер отдела продаж создает новый заказ для дилера в системе 1С:

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

После размещения заказа для него формируется заявка на транспорт, которая отправляется в отдел логистики.

Пример пользовательских требований к новой системе:

а) Автоматизировать создание заказа дилером, дать ему возможность набрать и разместить заказ самостоятельно, следить за его статусом выполнения, видеть историю всех своих заказов за время работы с компанией;
б) Дать возможность дилерам размещать предварительные заказы на неделю для возможности прогнозирования производства и отправки товара;
в) Дать возможность менеджеру отдела продаж видеть резерв товара на складе;
г) Дать возможность менеджеру автоматически определять количество поддонов и транспортных средств в зависимости от объема заказа;
д) Сохранять все документы по всем заказам дилера и дать возможность скачивать их всем заинтересованным лицам (менеджер, руководитель, бухгалтер, дилер).

На этом этапе аналитику важно содействие со стороны заказчика:

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



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

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

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

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

Полевые исследования


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



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

Технические особенности


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

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

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

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

В результате этапа исследования у нас, как правило, есть:

1. Сформулированные руководством цели и задачи для создания личных кабинетов;

2. Общее понимание и детальное описание бизнес-процессов, которые будут автоматизированы в результате их создания;

3. Список пользовательских требований от каждого типа пользователей личного кабинета;

4. Список систем, с которыми будет необходимо взаимодействовать, их описание и технические данные.

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

Проектирование


TO BE или проектирование новых бизнес-процессов и пользовательских сценариев


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

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

Пользовательское требование руководителя дивизиона:

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

Возможные сценарии на основе этого требования:

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

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

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

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

Выделение минимального набора сценариев для запуска


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

Пример MVP:

Личные кабинеты:

  • Генерального директора,
  • Руководителя дивизиона,
  • Менеджера продаж,
  • Маркетолога (зачеркнуто),
  • Сотрудника отдела логистики (зачеркнуто),
  • Главного бухгалтера (зачеркнуто).

Примеры сценариев руководителя дивизиона:

  • Установка плана продаж сотрудников,
  • Установка плана продаж по договору для дилеров,
  • Контроль статусов заказов (зачеркнуто),
  • Получение статистики продаж дивизиона по сотрудникам,
  • Получение статистики продаж дивизиона по дилерам,
  • Просмотр информации дилера.

Примеры сценариев дилера:

  • Просмотр условий работы с компанией, плана продаж,
  • Размещение заказа (зачеркнуто),
  • Просмотр статистики продаж за месяц,
  • Размещение заявления на получение маркетинговых материалов (зачеркнуто),
  • Участие в акции (зачеркнуто).

Функциональные требования


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

Пользовательское требование руководителя дивизиона:

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

Функциональные требования, которые из него вытекают:

1. Видеть общую информацию по отгрузкам дилерам своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города; конкретного менеджера;

д) конкретного дилера.

2. Устанавливать и менять план отгрузок на месяц для каждого менеджера дивизиона.

3. Видеть план компании по отгрузкам для дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) региона/города;

в) группы товаров (ССС, СЦС, ГСП, ПГП);

г) конкретного товара;

д) конкретного менеджера;

е) конкретного дилера.

4. Сравнивать (видеть одновременно) запланированные показатели с фактическими для того, чтобы увидеть отклонения и тенденции. Необходима возможность множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/ города; конкретного менеджера;

д) конкретного дилера.

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

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/города;

г) конкретного менеджера;

д) конкретного дилера.

6. Указывать, сколько дилеров предоставили информацию.

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

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/дивизиона и города;

г) конкретного менеджера;

д) конкретного дилера.

8. Видеть общую информацию о дебиторской задолженности дилеров своего дивизиона с возможностью множественного и одновременного выбора срока задолженности:

а) общая;

б) не более 14 дней;

в) 15-30 дней;

г) 31-45 дней;

д) 46-60 дней;

е) больше 61 дня.

9. Видеть список всех платежей дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) региона/города;

в) конкретного менеджера;

г) конкретного дилера.

10. Видеть прогнозы отгрузок продукции от дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города;

д) типа транспорта;

е) конкретного менеджера;

ж) конкретного дилера.

Создание структуры системы, права пользователей


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

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

Пример структуры кабинета дилера, * отмечена версия MVP:

1. Страница авторизации*

2. Рабочий стол*

3. Моя компания

а) Профиль*

б) Договор и дополнения*

в) Коммерческие условия*

г) О компании*

сотрудники*

склады*

территория работы*

контракты других производителей*

специализированные подразделения*

требования и преимущества*

д) Грузополучатели*

е) Объекты*

4. Каталог

а) Список товаров

б) Корзина

в) Оформление заказа

5. Заказы и платежи

а) Мои заказы

заказы

отгрузки

б) Мои платежи

в) Дебиторская задолженность

5. Продвижение

а) POS-материалы

б) Акции

в) Бонусы

6. Сдать отчет*

7. Помощь*

8. Настройки*

9. Контакты*

10. Уведомления*

а) Автоматические уведомления*

б) Сообщения*

в) Написать сообщение*

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

Вот так могут быть заданы права:

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

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

Структура данных всегда представлена в виде схемы:



Советы:

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




Прототип интерфейса


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



Техническое задание


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

Отрывок из технического задания:

3.1.1.1.1. Склады

Основная часть страница включает следующие элементы:

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

название (адрес) склада;

город, в котором расположен склад;

площадь склада (кв.м.);

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

дополнительная информация: текст с описанием склада.

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

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

2. Форма добавления нового склада со следующими полями, * отмечены обязательные для заполнения поля:

название (адрес) склада (текстовая строка)*;

город склада (текстовая строка)*;

собственный склад (чекбокс)*;

площадь склада, м2 (число)*;

дополнительная информация (текстовое поле).

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

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

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

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

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

Подытожим


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

Наш заказчик получил:

1. Личный кабинет для дилеров компании с возможностями:

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

делать предварительные заказы, тем самым предоставлять возможность планировать производство и транспорт для доставки,

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

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

2. Личные кабинеты сотрудников компании с возможностями:

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

получать и обрабатывать заказы дилеров в рамках своих полномочий и последовательных этапов общего процесса работы с заказами,

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

контролировать работу собственных сотрудников, получать отчеты о выполнении ими плана,

хранить и обрабатывать результаты маркетинговых акций

В результате работ по проектированию у участников проекта появилась возможность выбрать отвечающую всем требованиям технологию разработки (веб-технологии с использованием зарекомендовавших себя фреймворков), что позволило значительно (7-8 млн. рублей вместо 70 млн.) снизить стоимость разработки по сравнению с разработкой на основе известных программных продуктов, например SAP.
Подробнее..
Категории: Анализ и проектирование систем , Автоматизация , Проектирование и рефакторинг , Аналитика , Анализ , Исследования и прогнозы в it , Бизнес-модели , Анализ данных , Личный кабинет , Проектирование систем , Проектирование , 1с-битрикс , Автоматизация бизнеса , Проектирование интерфейсов , Автоматизация бизнес-процессов , Автоматизация предприятий , Предприятие

Recovery mode Как мы автоматизировали стрипушник на Walking street

29.10.2020 12:08:28 | Автор: admin

Есть у меня хороший друг. И есть у него одно очень замечательное свойство - он владелец русского стриптиз клуба на walking street ( кто не в теме это такая улица разврата и порока в Паттайе.

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

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

Хех, промелькнула мысль, а что если автоматизировать? Чтобы в момент пробития чека на кассе заказ автоматически капал на счёт девочки и чтобы в режиме реального времени можно было мониторить что начислили, какая комиссия, и сколько денег уже накапало на счёт!

Предложил другу - тот загорелся. Давай, говорит, попробуем.

И так - есть задача. Сообщить системе что за столом номер X гостя обслуживает девочка Y и все чеки которые будут пробиты на этот стол должны записываться на её счёт. Самая первая идея - поставить кард ридер на каждый стол и чтобы девчонки прикладывали RFID карты к нему. Компьютер на котором висит программа кассы подключён ко всем кардридерам и понимает за каким столом кто залогинился profit. Но столов 30 штук. Самые дальние в 15 метрах от кассы. Тянуть пачки проводов не наш вариант. Так не годится. нужно что то на батарейке и автономное чтобы информация по воздуху шла. Как кнопки вызова официанта. Стали искать есть ли беспроводные считыватели RFID - ничего вменяемого за адекватные деньги не нашли. И потом, карты будут терять, забывать головняк. надо использовать что то что всегда человек носит с собой. Биометрика тоже не катит - дорого. Отпечаток пальца было бы идеально если бы были недорогие, надёжные беспроводные считыватели.

И тут осенило - у всех всегда с собой телефоны. Надо идентифицировать телефон находящийся за столом X и от этого плясать. Стоп а зачем нам идентифицировать телефон? Пусть телефон идентифицирует стол и сообщит об этом кассе!Размещаем на столе маяк Beacon. Программа, запущенная в телефоне, по BLE сканирует маяки, маяк с наиболее сильным сигналом будет ближайший, а значит телефон находится за одним с ним столом! Читаем его ID, отсылаем в кассу, касса сверяется с списком столов и понимает что наша Y сидит за столом X. Все чеки пишутся на неё. Если за столом две девчонки - придут в кассу два сигнала и чек поделится пополам. Идеально.

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

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

Ну и в чем мы прокололись и почему не взлетело? Во первых, блин, батарейка. Производитель обещал 1-2 года непрерывной работы, а по факту, уже через месяц батарейка просаживалась и маяк терял значительно в мощности, пошли ложные срабатывания, когда маяк соседнего стола с более свежей батарейкой оказывался сильнее родного. Пришлось вводить программу администратора чтобы тот мог в ручном режиме поправить стол и указать что X сидит именно за столом Y а не Z. Во вторых оказалось что некоторые чехлы глушат BLE и телефон в чехле не видит ни одного маяка. Совсем. В третьих оказалось что даже телефон без чехлов может не ловить ни одного маяка если его держать в руке не правильно. А андроид при падении заряда батареи ниже 15 процентов любил снижать чувствительность приёмника и сигнал тоже не ловился, будто ни одного маяка нет в эфире. Самые беспроблемные оказались, ожидаемо, айфоны. Самые проблемные бюджетные андроиды и некоторые модели Samsung Galaxy. Ну а добило систему тот факт что девчонки довольно быстро просекли что могу подключаться к любому столу незаметно для гостей и администратора, даже если они с этими гостями не сидят. Постояла рядом 5 секунд и ушла. Для столов за которыми уже сидит девочка с гостем эту проблему решили просто - если вторая хочет подключиться к чеку этого стола - первая должна её заапрувить через приложение или кикнуть. Введение чата с техподдержкой через приложение тоже проблем не решило. Девочки тупили. Забывали включить блютуз, забывали включить вайфай, меню и промо акции грузились через медленный 3G потому что у клуба очень толстые стены и сигнал слабый очень..

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

Подробнее..
Категории: Анализ и проектирование систем , Управление персоналом , Разработка для интернета вещей , Досуг , Автоматизация бизнес-процессов , Стриптиз-клуб

Легкий способ автоматизировать бизнес-процессы, о котором не знает Аллен Карр

06.04.2021 10:06:21 | Автор: admin

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

Самый популярный способ автоматизировать бизнес-процессы

Обычно бизнес-процессы представляют вот такими схемами в стиле BPMN:

BPMN схема из ВикипедииBPMN схема из Википедии

Большинство процессов состоят из одних и тех же действий:

  • загрузка документа (или заполнение по готовой форме)

  • проход документа по цепочке сотрудников (которые либо вносят в него какую-то информацию, либо согласуют, либо просто уведомляются)

  • условия (определяют дальнейший ход процесса)
    и т. д.

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

Редакторы BPMN (и похожих на BPMN) схем реализованы во многих продуктах. Например: Тезис, ELMA, Bitrix. И это неплохой подход, который не хочется даже критиковать, но раз уж будем рассматривать альтернативы, нужно обозначить его недостатки:

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

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

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

В итоге, порог вхождения оказывается настолько высоким, что многие процессы проще организовать пересылкой документов по электронной почте. Ну и ведя реестр в экселе для порядку. Это не критика самой BPMN нотации. Часто без нее просто не обойтись. Вопрос вообще не в нотации, а в предлагаемом заказчику продукте. Кажется, для многих задач можно обойтись более простыми инструментами.

Альтернативный подход

Проблематика понятна, что же мы предлагаем?

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

А выглядит так:

Рассмотрим на примере простого процесса согласования:

  1. менеджер проекта может подать заявку на расходы (надо ему купить что-то для проекта)

  2. заявку должен согласовать начальник отдела

  3. затем одобрить финансовый директор

  4. затем бухгалтер отправляет оплату в банк

  5. и после того, как контрагент подтверждает оплату, менеджер закрывает вопрос

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

Заказчик нам говорит, что заявка на оплату это такая штука, у которой есть название, описание и сумма. С его слов будем наполнять нашу форму компонентами:

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

  • открыто

  • согласовано начальником отдела

  • согласовано финдиректором

  • оплачено

  • закрыто

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

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

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

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

Менеджеру проекта интересно видеть только свои заявки - фильтруем по столбцу Инициатор и группируем по Статусу. Тогда создаваемые им заявки будут попадать в группу Открыто, и в процессе работы он будет наблюдать, как они перемещаются в группу Согласовано начальником отдела, затем в Согласовано финдиректором и так далее:

Директору интересна общая картина, какие заявки в каком статусе и в каком отделе - делаем двухуровневую группировку по Начальнику отдела и Статусу:

Бухгалтеру вообще ничего не интересно, он просто хочет видеть какие заявки надо оплатить. Фильтруем только статус Согласовано финдиректором:

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

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

В общем, если бы Ален Карр знал об этом методе, то написал бы о нем книгу, которая, наверняка, стала бы бестселлером)

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

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

Что дальше

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

И да, все эти решения не новы, наверняка многие увидели знакомые приемы из CRMок и таск-трекеров (Jira, Redmine), чем-то это похоже и на Airtable, Notion, Planfix, и даже на Unity 3D (там тоже каждый игровой объект является набором компонентов, которые определяют его поведение). Но в приложениях, автоматизирующих процессы промышленных компаний, примеров не много.

Сейчас у нас в разработке несколько IT-продуктов (стек: Java, MongoDB, React) и мы в поиске разработчиков. Если вы знаете таких спецов, поделитесь с ними ссылкой. Если есть идеи, как это лучше реализовать, поделитесь мыслями. Если же видите слабые места этого подхода, я (тот, кто продвигает идею в нашей компании) открыт к критике и обсуждениям. Для связи - комменты и телега @planer484.

Подробнее..
Категории: Анализ и проектирование систем , Проектирование и рефакторинг , Erp-системы , Бизнес-модели , Документооборот , Saas / s+s , Автоматизация бизнес-процессов , Bpmn

Как я на собственном опыте убедилась, что управляющим компаниям в ЖК нужна автоматизация

22.10.2020 18:09:59 | Автор: admin

Привет, меня зовут Алиса, и я маркетолог компании HubEx, которая разрабатывает систему автоматизации сервисного обслуживания и управления выездным персоналом. Вернее, сегодня я просто обычный человек, который на своем опыте убедился, как сильно автоматизация нужна управляющим компаниям в ЖК. Что произошло?




В 6:30 утра я проснулась от того, что в ванной из трубы льет вода.

Паника! Все краны перекрыты, ведро-спасатель найдено, а вода все еще льется. Решение? Конечно, звонить в управляющую компанию и сообщать о неисправности. И вот, что из этого вышло.

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

    Что не так? При решении срочного вопроса я трачу время на поиск телефона и попытку связаться с диспетчером вместо того, чтобы просто отсканировать QR-код или подать заявку через мобильное приложение.
  2. Аллилуйя! Трубку в диспетчерской взяли. Мужчина, не представившись, выслушал мою истерику, спросил номер квартиры и сказал, что скоро будет. Но скоро это когда?

    Что не так? Я понятия не имею, что за специалист решает мой вопрос. Не знаю, на какой стадии решение. Скоро это 5 минут, 10, 15? Сантехник просто собирается, уже идет к моему дому или лег спать дальше? Заявка вообще принята или еще раз лучше перезвонить?

    Даже если бы я ждала те же 30 минут, но при этом видела через приложение, как меняется статус заявки (принята, специалист уже в пути), мне было бы намного спокойнее.
  3. Пострадали соседи записывая номер моей квартиры от руки, диспетчер ошибся. Вместо 345 квартиры сантехник пришел в 435. В 6:45 утра. Был немного удивлен, что его не рады видеть, перезвонил мне и уточнил номер квартиры.

    С: -А вы где?
    Я: -Эм, в квартире, где ж еще
    С: -А какой номер квартиры, еще раз?
    Я: -345.
    С: -Три, четыре, пять? О, я пришел не туда, так вот почему меня послали


    Что не так? Подавай я заявку электронно, номер моей квартиры отобразился бы сразу, и бедные соседи (простите, я не со зла) не просыпались бы в субботу в 7 утра, бедный сантехник не выслушивал бы новые факты о себе, а я не стояла бы с ведром под водопадом воды лишние 10 минут.
  4. Сантехник не понял, что именно за поломка у меня произошла. При описании проблемы я сказала, как мне казалось, все предельно точно: У МЕНЯ В ВАННОЙ ИЗ ТРУБ ВОДА ХЛЕЩЕТ!

    Но:
    а) я не могу точно объяснить, что это за труба, я ж мало того, что девушка, я еще и гуманитарий!
    б) на часах 7 утра, сантехник просто не услышал часть про трубу и пришел на вызов со стремянкой

    С: -Ну, где у вас течь?
    Я: -Да вот, труба же.
    С: -Это разве труба? Я думал, с потолка течет. Девушка, что ж вы сразу не сказали, что это у вас змеевик протекает?
    Я: -*минуты экзистенциального кризиса и печали, что труба не просто труба*


    Что не так? Человек иногда просто не может четко описать проблему он же не профессионал. Будь у меня возможность приложить к заявке видео, которое я сняла и скинула хозяйке квартиры в WhatsApp, сантехник бы сразу увидел, что речь идет о змеевике (да, теперь я в курсе, что это за штука).



Как итог, решение моей проблемы заняло:



1 час времени
3 звонка в диспетчерскую
2 звонка непосредственно специалисту
1 разбужденных по ошибке соседей
2 полных ведра воды

А как бы выглядела та же самая ситуация при автоматизации процессов?


  1. Увидев течь, я быстро подаю заявку на ремонт через приложение или просто сканирую QR-код с пометкой Аварийно-диспетчерская служба УК, который уже висит у меня в квартире. -10 минут и 3 звонка
  2. Через то же приложение я сразу вижу весь путь моей заявки: вот диспетчер ее принял, вот назначил сантехника Василия еще и лучшего на районе. Вот Василий выдвинулся ко мне. Да, все еще ждать, но теперь хотя бы понятны сроки. -мои расшатанные нервы
  3. Собираясь на вызов, Василий видит видео с неисправностью, которое я приложила к заявке. Сразу понимает, что это змеевик и не берет с собой лишний груз в виде стремянки.
  4. По пути Василий видит адрес, по которому ему надо прийти он подтянулся автоматически при создании заявки. Встроенный навигатор доведет его прямо до двери. Если вдруг Вася начинает сомневаться, что квартира 345 это три, четыре, пять, он пишет мне через то же самое приложение и уточняет, где я все-таки живу -1 ошибка диспетчера и 1 разбужденные в субботу с утра соседи
  5. Василий, как лучший сантехник района, видит, что нужно менять трубу, но можно сделать это позже. И сразу, на месте, создает заявку на будущее.


Вот так облегчило бы жизнь простое наличие в УК мобильного приложения для исполнителя и заказчика. И с такими проблемами и сами жильцы, и сантехники сталкиваются каждый день. А у вас такое было? Хотели бы узнать, как выглядела вся эта ситуация со стороны сантехника Василия и послушать историю Дмитрия, который уже работает в автоматизированной компании?

Подробнее..
Категории: Автоматизация , Crm-системы , Service desk , Автоматизация бизнес-процессов , Система автоматизации , История из жизни

Трудности при построении Общих центров обслуживания что делать? Расскажем на вебинаре

14.12.2020 20:04:49 | Автор: admin
Мы продолжаем серию вебинаров Как построить эффективный ОЦО, посвящённых построению и автоматизации Общих центров обслуживания. На вебинарах будет много интересного: разбор современных подходов и типичных ошибок при построении ОЦО, лучшие примеры автоматизации различных функций ОЦО и кейсы.

Тема нового вебинара: Трудности при построении Общего центра обслуживания и способы их преодоления
Дата: 24 декабря 2020 г. 11.00 12.00 (МСК)

Вебинар будет полезен


  • Руководителям департаментов ОЦО
  • Руководителям по развитию направлений ОЦО
  • Директорам по цифровой трансформации
  • ИТ-директорам компаний

Программа вебинара


  1. Вариативность процессов при оказании услуг. Как её снизить без потерь для компании.
  2. Необходимость управления организационными изменениями. Как подход к организационным изменениям, ориентированный на человека, поможет создать среду, в которой изменений не боятся, а ожидают и даже приветствуют.
  3. Обеспечение интерактивного и бесшовного взаимодействия поставщика и потребителя услуг. Создание единой точки контакта (Single Point of Contact) как технологическое и управленческое решение.

Спикеры: Иван Жигалов, генеральный директор компании ИТ Гильдия; Валерий Адлейба, менеджер по работе с ключевыми клиентами компании ИТ Гильдия.

Присоединяйтесь => Регистрация на вебинар

Ждём вас!
Подробнее..
Категории: Блог компании ит гильдия , Автоматизация бизнес-процессов , Itsm , Сервисные процессы , Общие центры обслуживания

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru