В Таблице 1 приведена оценка плановых затрат на проект по реализации данной концепции. Если говорить о суммарных трудозатратах, то они составляют 1528 рабочих часов или 191 день, т.е. больше чем полгода, в денежном выражении затраты на такой проект составят 764000 рублей. В данном проекте будут задействовано три проектные команды, отвечающие за поддержку систем 1С, К2 и CRM, т.е. проект по оптимизации и автоматизации процесса управления базой поставщиков потребует большого количества трудовых ресурсов.

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

В следующем разделе будет приведено описание варианта применения CRM-системы для целей управления базой поставщиков и составлена предварительная оценка трудозатрат.

2.2.3.2 Альтернатива №2 Использование Microsoft Dynamics CRM в качестве мастер-системы по хранению информации о всех контрагентах компании

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

2.2.3.2.1 Анализ используемых атрибутов в справочнике «Организации»

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

В системе CRM каждый клиент ведется в справочнике Организации, где сведения о клиенте содержат следующую информацию:

· Краткое/полное/юридическое наименование клиента наименование клиента

· Тип клиента (Юридическое лицо/Физическое лицо/Сотрудник КРОК)

· Финансовые реквизиты клиента: ИНН, ОКПО, КПП, ОГРН

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

· Признак нерезидента

· Статус клиента:

o Перспективный - возможный клиент компании

o Потенциальный - клиенты, по которым стартуют пресейл-активности

o Фактический - клиенты, по которым стартуют проекты, а также учитываются в бухгалтерской отчетности

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

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

Также в карточке организации есть возможность вести аналитику партнерской информации по следующим параметрам:

· Признак партнера: Данный параметр определяет текущий статус партнерства и имеет следующие значения:

o Не является партнёром;

o Действующий партнёр;

o Партнёр без партнёрского соглашения;

o Бывший партнёр;

o Новый партнёр

· Год начала партнерства

· Ключевой партнер

· Краткое описание партнера

· Список ответственных за партнерство

· Признак вендора

Помимо вышеописанных аналитик, для каждого партнера ведется учет информации о IT-решениях, по которым идет взаимодействие с партнером. Данная информация хранится в связанном справочнике «База решений». Также для анализа работы с партнерами компании используется справочник «База авторизаций» - здесь хранится информация о наградах, статусах и специализациях компании КРОК.

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

· Бухгалтерский баланс

· Выписка из ЕГРЮЛ

· Свидетельство государственной регистрации и постановки в налоговый учет

· Устав

· Правоустанавливающие документы в отношении имущества

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

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

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

2.2.3.2.2 Описание используемого механизма обработки дублей в MSCRM

Что касается процессов обработки дублей, то в системе MSCRM имеется модуль по автоматической обработке дублей «Дедубликация».

Модуль поиска и обработки дубликатов записей в Microsoft Dynamics CRM применяется для поиска и обработки дубликатов:

· контактов, а также дубликатов их телефонов, почтовых адресов, e-mail адресов, web-адресов, контактов организаций в рамках поиска и обработки дубликатов контактов;

· организаций, а также дубликатов их телефонов, почтовых адресов, e-mail адресов, web-адресов, контактов организаций, отношений с другими организациями в рамках поиска и обработки дубликатов организаций;

· настройки поиска и обработки дубликатов и отображаемой информации при поиске и обработке дубликатов.

Работа с модулем поиска и обработки дубликатов записей разделяется на следующие задачи:

· Поиск дубликатов записей:

o Ручной поиск дубликатов записей;

o Пакетный поиск дубликатов записей;

· Обработка дубликатов записей:

o Работа со списком запросов на обработку дубликатов записей;

o Использование мастера объединения записей;

· Настройка модуля поиска и обработки дубликатов записей:

o Настройка поиска дубликатов записей;

o Настройка выводимой информации при поиске и обработке дубликатов записей.

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

Атрибуты первой и второй записи, у которых в выбранном правиле значение “Поиск дубликатов” = Да, сравниваются друг с другом. Если при сравнении, достигнут указанный процент подобия атрибута двух записей, то присваивается определенная оценка. После сравнения всех необходимых атрибутов, полученные оценки складываются и сравниваются с порогом сопоставления, определенным для выбранного правила. Если порог сопоставления достигнут, то две записи считаются потенциальными дубликатами. Доступ к настройкам правил поиска дубликатов имеют только системные администраторы.

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

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

1. Найти нужную запись, задав необходимый параметр в поиске

2. Выбрать все или несколько записей, но больше одной, в списке найденных записей и нажать кнопку «Работа с дубликатами» на панели операций;

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

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

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

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

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

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

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

В открывшейся группе потенциальных дубликатов можно:

· сформировать запрос из выбранных записей, путем проставления галок, выбора главной записи и нажатия кнопки «Создать запрос»;

· отклонить группу - если записи были ошибочно определены как дубликаты;

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

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

2.2.3.2.3 Описание бизнес-процесса согласования создания/изменения информации о клиенте

Что касается процесса управления изменениями в компании КРОК, данный бизнес-процесс разбит на 2 подпроцесса: согласование создания записи в базе клиента и согласование изменения информации по клиенту. Оба процесса автоматизированы в системе К2, и на текущий момент разработан интеграционный механизм взаимодействия между системой автоматизации бизнес-процессов и системой CRM, с помощью которого в зависимости от принятого решения на каждом шаге данные в системе CRM по клиенту актуализируются. Условиями запуска процесса по созданию клиента является изменения статуса клиента на «Потенциальный» или «Фактический» либо создание записи клиента с этими записями.

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

Далее в зависимости от указанных данных, в процессе стартуют следующие шаги:

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

· Согласование директора клиента. Если при создании организации были указаны директора клиентов, то директора департаментов компании принимают решения по отклонению или утверждению указанного директора клиента.

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

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

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

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

Далее, если пользователь хочет повысить статус клиента с потенциального до фактического или отредактировать следующие данные по организации со статусом «Фактический»:

· Краткое наименование;

· Юридическое наименование;

· ИНН;

· КПП;

· ОКПО;

· Индекс;

· Код города;

· Улица, дом;

· Страна;

· Нерезидент;

· Директор клиента;

· Указан признак «Вендор»

то автоматически запускается процесс согласования изменений клиента.

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

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

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

· Согласование ДК. Как и в процессе создания клиента, решение по изменению состава директоров клиентов по организации принимают директора департаментов компании.

По завершению процесса данные обновляются данные по организации в системе CRM.

2.2.3.2.4 Оценка трудозатрат на доработки системы под ведения базы поставщиков

Исходя из описания имеющегося функционала управления базой клиентов в системе Mycrosoft Dynamics CRM 4.0. доработки, которые потребуются для приспособления CRM-системы для управления базой поставщиков, будут следующие:

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

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

· Разработка механизма автоматизации нового бизнес-процесса в системе К2. Здесь необходима разработка новой логики процесса управления изменения информации о поставщиках, а также логика определения ответственных за шаг процесса.

· Интеграционный механизм с системой 1С по всем контрагентам. В данном случае нужно переделать логику синхронизации изменений по клиентам и по поставщикам.

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

Таблица 2 - Оценка трудозатрат

Название задачи	Длительность	Названия ресурсов	Трудозатраты	Общие затраты
Кастомизация CRM	2 дней		32 ч	16000,00р.
Анализ	2 дней	Аналитик 1С	16 ч	8000,00р.
Разработка	1 день	Разработчик 1С	8 ч	4000,00р.
Тестирование	1 день?	Тестеровщик 1С	8 ч	4000,00р.
Интеграционный механизм с системой автоматизации БП	13 дней		208 ч	104000,00р.
Анализ	5 дней	Аналитик 1С;Аналитик К2	80 ч	40000,00р.
Разработка	2 дней	Разработчик 1С;Разработчик К2	32 ч	16000,00р.
Тестирование	6 дней	Тестеровщик 1С;Тестеровщик К2	96 ч	48000,00р.
Интеграционный механизм с системой 1C по всем контрагентам	9 дней		144 ч	72000,00р.
Анализ	3 дней	Аналитик 1С;Аналитик CRM	48 ч	24000,00р.
Разработка	3 дней	Разработчик 1С;Разработчик CRM	48 ч	24000,00р.
Тестирование	3 дней	Тестеровщик 1С;Тестеровщик CRM	48 ч	24000,00р.
Разработка механизма автоматизации нового БП в системе К2	35 дней		560 ч	280000,00р.
Анализ	10 дней	Аналитик 1С;Аналитик К2	160 ч	80000,00р.
Разработка	10 дней	Разработчик 1С;Разработчик К2	160 ч	80000,00р.
Тестирование	15 дней	Тестеровщик 1С;Тестеровщик К2	240 ч	120000,00р.

На основе анализа проблем компании «КРОК» в процессе управления базой поставщиков, а также оценки возможности систем 1C Предприятие 8.2 и Microsoft Dynamics CRM и оценки требуемых трудозатрат, в следующей главе будет приведено описание обоснования выбора системы, а также будут определены критерии эффективности для данного процесса.



Глава 3. Применение системы «MSCRM» для управления отношениями с поставщиками и описание новой концепции ведения контрагентов в компании ЗАО «КРОК»

3.1 Анализ рассмотренных альтернатив и обоснование выбора системы MSCRM

В ходе анализа систем 1С Предприятие 8.2 и Microsoft Dynamics CRM 4.0 были рассмотрен текущий функционал систем, а также была проведена оценка трудозатрат для реализации необходимых доработок. В данном случае образом эти два варианта рассматривались со следующих позиций: будет ли быстрее и выгоднее разработать новый функционал ведения базы поставщиков с нуля или же доработать уже имеющийся функционал, а также какая из альтернатив позволит повысить эффективность управления базой поставщиков.

Рассматривая оценку трудозатрат, можно утверждать, что бюджет проекта по реализации концепции управления поставщиков с помощью системы 1С почти в 1.5 раза превышает планируемый бюджет проекта по реализации ведения базы поставщиков с помощью системы Microsoft Dynamics CRM, и тоже самое можно сказать и про сроки реализации проекта.

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



3.2 Описание нового процесса управления изменениями контрагентов

3.2.1 Описание новой карточки с учетом информации по поставщику

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

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

В рамках данной работы была доработана карточка организации в CRM, а именно добавилась новая вкладка «Поставщик/подрядчик», на которой указаны следующие реквизиты, относящиеся только к данным по поставщику (Таблица 3):

Таблица 3 Реквизиты поставщика

Название атрибута	Описание	Доступность
Поставщик/ подрядчик	Обязательно указание хотя бы одного из признаков «Поставщик/ подрядчик» или «Клиент» (на одноимённой вкладке)	Нельзя снять признак «Поставщик/ подрядчик» по согласованным потенциальным и фактическим контрагентам
Вид деятельности	Обязательно, для поставщика/ подрядчика. Возможен выбор нескольких значений одновременно.	Не доступно для редактирования, если не указан признак «Поставщик/ подрядчик»
Ответственный от КРОК	Ответственный от отдела закупок за дилера/дистрибьютора. Данное поле обязательно для заполнения, если выбран вид деятельности Дилер/дистрибьютор или Поставщик/подрядчик под собственные нужды.	Не доступно для редактирования, если не указан вид деятельности «Дилер/дистрибьютор» или «Поставщик под собственные нужды».
Ответственный департамент	Департамент ответственный за вендора или подрядчика. Сотрудники от выбранного департамента (если выбран производственный департамент) согласуют финансовые реквизиты в процессе согласования контрагента	Не доступно для редактирования, если не указан вид деятельности равный значению «Вендор» или «Подрядчик».
Основной контакт	Данное поле необязательно для заполнения. Здесь можно указать официального представителя поставщика, и с которым сотрудники компании могут связаться по вопросам совместного сотрудничества	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»
Телефон	Телефон для связи с поставщиком	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»
Email	Адрес электронной почты для связи с поставщиком	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»
Продукты производителя	Здесь указывается перечень продуктов, предоставляемых поставщиком/подрядчиком	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»
Профиль компании	Краткое описание деятельности поставщика/подрядчика	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»
Направление деятельности	Здесь указывается одно из направлений деятельности компании КРОК, к которому может относиться поставщик/подрядчик	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»
Выполненный с КРОКом проект	Перечень проектов, в котором принимал участие данный поставщик	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»
Направление деятельности субподрядчика в проекте с КРОКом	Здесь указывается одно из направлений деятельности компании КРОК, в рамках к которому может относиться поставщик/подрядчик в ходе проекта	Доступно для заполнения, если проставлен признак «Поставщик/подрядчик»

Теперь сценарий использования системы будет выглядеть следующим образом:

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

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

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

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

5. При повышении статуса контрагента до фактического автоматически должен проставляться признак обязательной проверки чистоты. У пользователя должна быть возможность снять этот признак, если планируемые проекты не будут превышать определённой суммы контракта. В таком случае пользователь должен оставлять комментарий, где он аргументирует отмену проверки чистоты, при этом пользователь, отменивший проверку, должен быть указан на форме.

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

7. Если контрагент также является партнером компании, то для него есть возможность вести учет по текущему статусу партнёрства, вести список ответственных лиц за поставщика, определяя для каждого определенную зону ответственности. Также для каждого партнера есть возможность указать решение компании КРОК, в рамках которого осуществляется взаимодействие с партнером.

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

3.2.2 Описание нового процесса по согласованию поставщиков и клиентов

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

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

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

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

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

Если говорить, про процесс согласования контрагентов, то его можно представить в следующем виде:

1. Условия старта процесса согласования поставщика, согласования создания и изменения клиента могут быть объединены следующим образом

Процесс согласования контрагента должен стартовать при выполнении следующих условий:

o был создан контрагент, статус которого выше перспективного, т.е. потенциальный или фактический;

o у существующего контрагента повысили статус до потенциального и до фактического;

o у фактического контрагента были изменены финансовые реквизиты;

o у фактического контрагента с признаком клиента был изменен состав директоров клиента;

o у фактического поставщика изменили ответственного;

o пользователь проставил признак обязательной проверки чистоты контрагента;

o был изменен виде деятельности на Вендор или Дилер/Дистрибутор;

o добавление признака клиента фактическому контрагенту.

2. Процесс согласования контрагента может включать в себя объединение шагов процессов создания или изменения клиентов.

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

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

· отдел закупок, если это дилер/дистрибутор;

· ответственный департамент за вендора, если контрагент - вендор;

· отдел подряда, если контрагент- подрядчик.

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

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

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

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

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

3.2.3 Описание проекта по реализации новой концепции

В данном разделе будут рассмотрены основные этапы проекта по доработке CRM и BPM систем компании «КРОК» для управления информацией всей базы контрагентов. Целевая аудитория состоит из следующих лиц: сотрудники отдела закупок, финансового департамента, коммерческого отдела, отдела маркетинга, юридического отдела.

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

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

1. автоматизировать процесс согласования изменений в базе поставщиков;

2. сократить процесс согласования контрагентов в 2 раза;

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

В рамках SWOT-анализа проекта были определены сильные и слабые стороны, возможности и угрозы проекта.

Анализируя преимущества данного проекта, можно выделить следующие основные возможности и сильные стороны:

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

2. сокращение времени обработки информации о поставщиках;

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

4. улучшение качества отчетности о работе с поставщиками.

Если говорить о недостатках данного решения и возможных рисках, то можно выделить следующие недостатки:

1. потребуется время, чтобы пользователи, которые не работали с CRM системой, (сотрудники отдела закупок и отдела подряда), привыкли к новой системе и к новому процессу управления базой поставщиков. Также потребуются дополнительные трудозатраты по обучению сотрудников;

2. после внедрения данной доработки возрастет нагрузка по поддержке системы CRM и системы BPM;

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

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

Описанные выше риски и недостатки проекта присущи любому процессу реализации новой концепции.

Снизить степень влияния рисков на успех проекта можно с помощью следующих решений:

· сильная вовлеченность заказчика в процесс обновления концепции и доработок информационных систем поможет более оперативно принимать управленческие решения по выбору способов реализации обновлённого процесса;

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

Организационная структура проекта выглядит следующим образом:

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

· составлять план работ и согласовывать его с руководителем проекта будут менеджеры обеих систем К2 и CRM. Также они курируют выполнение требований каждой системы;

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

Что касается самих работ по проекту, то здесь можно выделить следующие пункты (Таблица №3):

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

4. Разработка. Данный блок работ включает в себя разработку функционала системы по проектировочной документации, разработанной аналитиком.

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

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

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

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

Таблица 4 - Оценка плановых трудозатрат

Название задачи	Длительность	Трудозатраты	Затраты
Анализ и проектирование	19 дней	336 ч	168 000,00р.
Обследование предметной области, ее описание	3 дней	72 ч	36 000,00р.
Разработка модели «как есть». Выявление проблемных зон	3 дней	96 ч	48 000,00р.
Проработка новой концепции процесса, построение модели to be	3 дней	48 ч	24 000,00р.
Обследование и определение требований к архитектуре инфраструктурного решения	3 дней	24 ч	12 000,00р.
Формализация требований заказчика. Подготовка ТЗ	4 дней	48 ч	24 000,00р.
Проектирование К2	3 дней	24 ч	12 000,00р.
Проектирование CRM	3 дней	24 ч	12 000,00р.
Разработка	5 дней	80 ч	40 000,00р.
Кастомизация и разработка функционала CRM	5 дней	40 ч	20 000,00р.
Кастомизация и разработка функционала К2	5 дней	40 ч	20 000,00р.
Тестирование	15 дней	364 ч	182 000,00р.
Разработка тест-планов для локального тестирования CRM	2 дней	16 ч	8 000,00р.
Разработка тест-плана для интеграционного тестирования	5 дней	60 ч	30 000,00р.
Локальное тестирование CRM	2 дней	16 ч	8 000,00р.
Доработка системы и устранение замечаний по итогам тестирования CRM	1 день	16 ч	8 000,00р.
Локальное тестирование К2	2 дней	16 ч	8 000,00р.
Доработки и устранение замечаний по итогам BPM	1 день	16 ч	8 000,00р.
Интеграционное тестирование на тестовом контуре	4 дней	48 ч	24 000,00р.
Доработка системы и устранение замечаний на ТК	2 дней	64 ч	32 000,00р.
Интеграционное тестирование на предрелизном контуре	4 дней	64 ч	32 000,00р.
Доработка системы и устранение замечаний на ПК	2 дней	48 ч	24 000,00р.
Приемочное тестирование	4 дней	112 ч	59 200,00р.
Подготовка сценариев для приемочного тестирования	2 дней	80 ч	43 200,00р.
Проведение приемочного тестирования	2 дней	32 ч	16 000,00р.
Внедрение	4 дней	48 ч	24 000,00р.
Подготовка плана внедрения	2 дней	24 ч	12 000,00р.
Накат на бой и тестирование	2 дней	24 ч	12 000,00р.
Эксплуатация	4 дней	48 ч	24 000,00р.
Обучение ключевых и конечных пользователей	4 дней	48 ч	24 000,00р.

Если говорить про трудозатраты, то длительность проекта составит 51 день, а бюджет всего проекта составит 497200 рублей.

3.3 Оценка эффективности применения предложенной концепции управления базой поставщиков в компании «КРОК»

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

Среди основных критериев эффективности в данном случае можно выделить следующие:

· длительность процесса согласования, соответственно онва должна сократиться;

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

Если рассматривать работу с информацией о поставщиках в системе Navision, то можно выделить следующие ключевые моменты (Рисунок 5):

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

2. Если поставщик являлся еще и клиентом компании или вендором, то его нужно было также завести и в CRM. При этом в CRM хранился фиктивный признак вендора.

3. Если клиент являлся поставщиком, то его нужно было также завести в системе Navision.

Рисунок 6. Создание поставщика в системе Navision

Рассматривая новую общую схему процесса по управлению базой поставщиков, то здесь можно выделить следующие моменты:

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

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

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

4. Не зависимо от типа контрагента, запускается проверка чистоты контрагента

Сравнивая описания процессов до и после, можно сделать вывод, что предложенное решение по ведению единого справочника контрагента в системе Microsoft Dynamics CRM приведет к следующим изменениям:

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

Рисунок 7. Ведение контрагентов в CRM

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

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

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

Соответственно время, потраченное на ведение общей базы контрагентов сократиться как минимум в 2 раза за счет объединения карточки клиента и поставщика. Также вовлеченность нескольких ответственных позволит быстро и оперативно принимать решение в ходе процессов, что соответственно сократит среднее время согласования изменения. По оценкам сотрудников проекта К2, среднее время согласования клиента до внедрения нового процесса составляло около 5 дней, если же говорить про согласование поставщика, то здесь сложно дать оценку, т.к. до внедрения нового процесса согласование нового поставщика происходило только по электронной почте. После обновления процесса среднее время согласование для клиента сократиться до 2 дней за счет наличия общих шагов проверки чистоты и согласования финансовых реквизитов для поставщика и клиента, а также за счет четкого определения ответственных лиц за каждый процесс. На графике №1 продемонстрирована динамика значений максимальной длительности согласования в течение 8 месяцев.

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

Рисунок 8. График динамики средней длительности согласования

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



Заключение

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

Во второй главе был рассмотрен процесс управления базой поставщиков в компании «КРОК» и был выявлен ряд недостатков, таких как отсутствие автоматизированного и регламентированного процесса согласования изменений по поставщикам, а также не соответствие используемой системы Navision требованиям по атрибутике поставщика. Соответственно, в результате выявленных недостатков текущего процесса, была построена новая модель процесса ведения базы поставщиков. Был также проведен анализ информационных систем компании на предмет наличия требуемого бизнесом функционала, а также сложности доработок системы. Для анализа были выбраны имеющаяся CRM система компании Mycrosoft Dynamics CRM и новая система 1С ERP, которая сейчас внедряется. По результатам анализа оказалось, что для системы 1С требуется в 2 раза больше трудозатрат, чем при доработках текущей CRM системы. Также система CRM уже имеет необходимый функционал, который требуется для ведения поставщиков, а именно обработка дубликатов, ведение контактной и партнерской информации, поэтому была выбрана система CRM.

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

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



Список литературы

1. О.А. АНАНЬЕВ SRM-СИСТЕМЫ ДЛЯ МАЛОГО И СРЕДНЕГО БИЗНЕСА // ЭКОНОМИЧЕСКИЕ НАУКИ. 2010. №1. С. 107-109.

2. Титоренко Г.А. Информационные технологии управления. - 2 изд. - М.: ЮНИТИ-ДАНА, 2003

3. Черкашин П. А. Готовы ли Вы к войне за клиента? Стратегия управления взаимоотношениями с клиентами (CRM).. М.: ООО "ИНТУИТ.ру", 2004. 384 с.

4. Гудова, И, В СИСТЕМА УПРАВЛЕНИЯ ВЗАИМОДЕЙСТВИЕМ ПОСТАВЩИКОВ И ПОТРЕБИТЕЛЕЙ // Вестник СибАДИ. 2010. №3. С. 65-69.

5. Лайсонс К. Управление закупочной деятельностью и цепью поставок / К. Лайсонс, М. Джиллингем; пер. с англ. - 6-е изд. М.: Инфра-М, 2012. 797 с.

6. Веселов А. Организация работы отдела продаж. Системный подход / А. Веселов, М. Горбачев. М.: Феникс, 2013. 176 с.

7. Уотерс Д. Логистика. Управление цепью поставок / Д. Уотерс. М.: ЮНИТИ-ДАНА, 2012. 503 с.

8. Модели жизненного цикла программного обеспечения // Хабрахабр URL: https://habrahabr.ru/post/111674/ (дата обращения: 08.03.2016).

9. Руководство к Своду знаний по управлению проектами (Руководство PMBOK®). -- Пятое издание. / Project Management Institute, Inc. 14 Campus Boulevard Newtown Square, Pennsylvania 19073-3299 US, 2013.

10. Преимущества системы CRM // URL: http://www.crm-lite.ru/ (дата обращения: 01.04.2016).

11. Иванова А, Борисова В УПРАВЛЕНИЕ ВЗАИМООТНОШЕНИЯМИ С ПОСТАВЩИКАМИ как способ повышения уровня логистического сервиса поставщиков производственной компании. Часть первая // Логистика. 2015. №10. С. 26-31.

12. Иванова А, Борисова В УПРАВЛЕНИЕ ВЗАИМООТНОШЕНИЯМИ С ПОСТАВЩИКАМИ как способ повышения уровня логистического сервиса поставщиков производственной компании. Часть вторая // Логистика. 2015. №11. С. 26-31.

13. Сергеев В.И., Эльяшевич И.П. Логистика снабжения: Учебник для вузов. М.: Рид Групп, 2011. 416 с.

14. Шевченко М. Ю. ПРОЦЕСС «УПРАВЛЕНИЯ ПОСТАВЩИКАМИ»: ТРАДИЦИОННЫЙ И ЛОГИСТИЧЕСКИЙ ПОДХОДЫ // Экономические науки. 2015. С. 1-14.

15. Управление закупками - один из ключевых элементов управления затратами // Лаборатория HRD URL: http://hrd.ru/stati/o-zakupkah/upravlenie-zakupkami/ (дата обращения: 07.03.2016)

16. Выбор и оценка поставщика. По материалам одного проекта. // Лаборатория HRD URL: http://hrd.ru/stati/o-zakupkah/vybor-i-ocenka-postavshchika/ (дата обращения: 07.03.2016).

17. Петров В.Н Информационные системы. СПб: Питер, 2007.

18. В.В. Трофимов Информационные системы и технологии в экономике и управлении. М: Высшее образование, 2009. 480 с.

19. Пейн Эдриан Руководство по CRM. Путь к совершенствованию менеджмента клиентов. Гревцов Паблишер, 2007. 384 с.

20. Кудинов А. CRM: Практика эффективного бизнеса. 2 изд. ООО "1С-Паблишинг", 2012. 384 с.

Размещено на Allbest.ru

...