56
раз в час во все значимые производственные базы данных.
Рис.1. Схема получения и импорта глобальных данных по
производству товара
2 уровень – информация по логистике товара. Очень важный блок,
который частично формируется так же, в центральном офисе. Однако, при
анализе полученных данных выяснилось, что имеется разница связанная с
размером паллет, используемых в Европе и России из-за чего вложенность
товара на паллете разная. Это информация необходима для департамента
логистики, чтобы правильно рассчитать вес и кол-во паллетомест при
транспортировке товара до клиента. Так же, этот параметр является
определяющим при контроле производства товара – вес с упаковкой, вес без
упаковки, вложенность в короба и паллету – все учитывается при выходе
товара с производства на склад.
Рис. 2. Схема процесса передачи и получения логистической
информации по товару
На данной схеме мы видим, что информация полноценно ведется на
стороне центральной команды, но в российский департамент поступает
нерегулярно, никто за передачу информации не отвечает. Оператор БД на
заводе вводит данную информацию вручную в ERP систему.
3 уровень – описание сырьевой базы товара. Это важный пункт в
формировании себестоимости, цены реализации товара, финансовой,
налоговой и таможенной отчетности и с точки зрения создания официальных
57
документов на товар, а также для своевременного формирования сырьевой
базы для производства товара. В данном бизнес процессе участвует
департамент закупки, который отвечает за ввоз импортного и закупку
российского сырья, за взаимоотношения с поставщиками. Для централизации
и контроля за всеми контактами с поставщиками, а также унификация
карточек сырья была создана база данных на стороне центральной команды
во Франции. Департамент закупок пополняет данную базу на своей стороне
и далее, подготовленный контракт по закупу автоматически импортируется в
ERP систему.
Рис. 3. Схема подготовки, приема и передача данных по
сырью
4 уровень – маркетинговое описание товара. Фотографии товара,
описание и контроль потребительской упаковки товара, формирование акций
на товар, контроль за акциями. Представление товара в различных средствах
масс медиа, в том числе, поддержание единого представления продукции в
сети Интернет. В настоящий момент все ведется вручную и не коррелирует с
единой БД продукции.
Рис. 4. Схема подготовка данных по продукции департаментом
маркетинга
5 уровень – коммерческое описание товара. Формирование
всевозможных уровней цен для различных категорий покупателей.
Формирование коммерческих акций, программы скидок на товар, ввод/вывод
товара из обращения.
58
Полная верхнеуровневая схема формирования данных по карточке
товара предоставлена в Приложении 1.
После получения верхнеуровневой модели были проведены работы по
анализу бизнес процесса создания, хранения, изменения, использования
данных по продукту в компании на основании требований к организации
процесса, учитывающие рекомендации стандарта ИСО 9001 – результаты
представлены в таблице 1. Стандарты ИСО серии 9000 рекомендуют
использовать цикл PDCA (Plan-Do-Check-Act) для создания системы
постоянного улучшения процесса.
Таблица.1. Анализ процесса по отношению к типовым
требованиям
№
Требование к типовому
процессу
Соответствие
1. Требования к владельцу процесса
1.1.
Должен существовать один
владелец процесса
не соответствует
на текущий момент в компании нет
владельца процесса в целом и в
некоторых случаях отсутствуют
ответственные за ввод и целостность
части данных в БД.
1.2.
Полномочия и ответственность
владельца процесса должны быть
четко определены
не соответствует
требуется определить полномочия и
ответственность владельца процесса
в должностной инструкции
1.3.
Не должно быть пересечений
полномочий и ответственности с
другими руководителями
организации
не соответствует
2. Границы процесса
2.1.
Границы процесса должны быть
четко определены (по функциям
и ответственности
руководителей) и зафиксированы
документально
Не соответствует.
Документально не закреплены
границы процесса.
2.2.
Границы функциональных
подразделений процесса должны
быть четко определены
Не соответствует.
Нет четко распределенной границы
функциональных подразделений.
3. Регламентирующие документы
59
3.1.
Должно существовать
действующее описание процесса
в целом
Не соответствует
3.2.
Должны существовать
действующие положения о
подразделениях
Не соответствует
3.3.
Должны существовать
действующие должностные
инструкции
Соответствует частично.
Для каждой системы ввода и
хранения данных существуют
инструкции для работы.
3.4.
Должны существовать
действующие методики
(внутренние стандарты)
Не соответствует
3.5.
Должна функционировать
система актуализации
документации
Не соответствует
3.6.
Процесс должен соответствовать
существующим законодательным
актам и нормативным
документам, регламентирующим
выполнение процесса
Не соответствует
4. Выходы процесса
4.1.
Выходы процесса должны быть
четко определены
Соответствует
4.2.
Пользователи каждого выхода
процесса должны быть четко
определены, потребности
пользователей специфицированы
Соответствует частично.
4.3.
Должны существовать
спецификации требований на
каждый выход процесса
Не соответствует. Отсутствуют
спецификации требований на
каждый выход процесса
4.4.
Каждый выход должен быть
закреплен за ответственным
исполнителем
Соответствует частично.
Частично выходы закреплены за
ответственным исполнителем
процесса
4.5.
Должна функционировать
система контроля качества
выходов процесса
Не соответствует
5. Входы процесса
5.1.
Входы должны быть четко
определены
Соответствует.
Четко определены входы процесса
5.2.
Поставщики каждого входа
процесса должны быть четко
определены, требования к
поставщикам специфицированы
Соответствует частично.
Распределены пользователя каждого
выхода технологического процесса,
однако их потребности не
специфицированы
60
5.3.
Должна существовать
спецификация требований на
каждый вход процесса
Не соответствует
5.4.
Каждый вход должен быть
закреплен за ответственным
исполнителем
Соответствует частично.
5.5.
Должна существовать система
входного контроля качества
Не соответствует.
Отсутствует система входного
контроля качества.
6. Ресурсы
6.1.
Ресурсы должны быть четко
определены
Не соответвует
6.2.
Должна существовать
спецификация требований к
каждому ресурсу
Не соответствует
6.3.
Каждый ресурс должен быть
закреплен за ответственным
исполнителем (материально
ответственным лицом)
Не соответствует
7. Показатели процесса
7.1.
Должны быть определены и
использоваться показатели
эффективности процесса
Не соответствует
7.2.
Должны быть определены и
использоваться показатели услуг
процесса
Не соответствует
7.3.
Должна существовать система
сбора и использования данных
удовлетворенности клиентов
процесса
Не соответствует
При анализе бизнес процессов были выявлены следующие
недостатки, требующие улучшений:
1. Нет единого владельца процесса, который бы имел понимание о всех
составляющих продукта и мог бы грамотно развивать данное
направление в компании.
2. Нет регламентирующих процедур, спецификаций на ввод
номенклатуры, части инструкций по вводу и модификации данных.
3. Нет разграничения по правам доступа сотрудников к изменению
данных.
61
4. Вся информация делится на несколько потоков, некоторые из которых,
формируются вручную, что неизбежно приводит к ошибкам в данных.
5. Некоторые потоки данных не пересекаются друг с другом, что
приводит к появлению противоречивой, дублирующей информации.
6. Некоторые потоки данных передаются между системами множество
раз, что приводит к потере данных в момент передачи, искажению
данных полученных из более достоверного источника, неверной
коммерческой отчетности.
7. Отсутствуют точки контроля за чистой данных и процедура
согласования изменения данных.
Описание проекта Управление мастер данными в компании ЗАО
«Рускан»
Мастер данные – это данные с важнейшей для ведения бизнеса
информацией: о клиентах, продуктах, услугах, персонале, технологиях,
материалах и так далее, в том числе и справочные данные. Они относительно
редко изменяются и не являются транзакционными.
Цель управления мастер данными — удостовериться в отсутствии
повторяющихся, неполных, противоречивых, не корректных данных в
различных областях деятельности организации. Исключить «человеческий
фактор» при создании карточки товара. Разработать единый источник мастер
данных для всех потребителей информации – конечных пользователей и
информационных систем. Унификация ввода мастер данных в ИС. Карточки
товаров во всех базах данных Navision имеют идентичные значения, кроме
полей, указанных в Исключении.
Периметр проекта: данный проект предназначен для использования
сотрудниками финансового департамента, департамента маркетинга,
производственного департамента, IT. Так же он будет использоваться в
качестве руководства к действию для администратора базы данных.
62
Директора филиалов будут информированы о контактах при возникновении
проблем при продаже и покупке ГП.
Управление проектом состоит из 2 частей:
1. Подготовка данных для изменения, исходных данных для мастер БД.
Подготовка регламентов работы с учетом измененного процесса.
2. Подготовка и создание мастер БД, создание и настройка интерфейсов
обмена. Подготовка документации для последующего
администрирования. Настройка обслуживания БД.
Ограничения:
вне зависимости от способа ввода мастер данных в систему (ручной,
автоматический, полуавтоматический ввод) – они должны быть
разблокированы вручную, тем самым будет подтверждаться их
правильность владельцем информации;
справочник товаров, цен, групп скидок, промо-акций автоматически
обновляется в базах филиалов, на основании информации заведенной в
базе ЗАО Рускан, по установленному расписанию;
сотрудники филиала не имеют права изменять мастер данные,
полученные из базы ЗАО Рускан. При нахождении ошибки они должны
сообщить ответственному сотруднику в ЗАО Рускан и дождаться
изменения информации при следующем обмене;
обмен возможен только при наличии Интернета в офисе ЗАО Рускан
и/или в филиале;
Классификация мастер данных
1. Группа учета - справочные данные, которые напрямую влияют на
формирование финансового результата компании. В идеальном состоянии, в
течении года, изменяться не должны.
2. Группа контрагентов – справочник клиентов, поставщиков. При
добавлении, изменении нового контрагента используются данные из группы
учета, в качестве основных настроечных параметров.
63
3. Группа номенклатуры – справочник товаров, цен, скидок, акций.
Достаточно динамичные данные. При добавлении, изменении номенклатуры
используются данные из группы учета, в качестве основных настроечных
параметров.
4. Группа WW – справочные данные, которые являются общими для
всего Royal Canin – справочник спецификации крокетов, контракты по
закупкам сырья, спецификации производства ГП, справочник WW Main Item,
CustomerClass, Product Range.
Подготовительные задачи проекта:
определить какая информация является мастер данными в системе;
определить единого владельца мастер данных, а так же совладельцев,
отвечающих за различные уровни ввода информации и составить
справочник для обращений филиалов в случае конфликтной ситуации;
определить схему движения и взаимодействия между собой мастер
данных;
описание спецификаций ввода мастер данных по определенным
справочникам;
создание регламентирующих документов, инструкций, обучение
пользователей на местах;
описание единого стандарта ввода номенклатуры, контрагентов в
различных системах;
описание синхронизации справочника номенклатуры, цен, промо-
акций, скидок;
описание прав доступа для ввода, модификации, удалении данных;
описание точек контроля за чистотой данных.
Прикладные задачи проекта:
консолидация существующих данных, их преобразование
(сопоставление) к единому стандарту из различных источников.
нормализация данных – вычистка, устранение дублей и ошибок в
данных, сопоставление (mapping) данных, собранных из разных
64
источников, унификация, пополнение неполных данных, первичная
структуризация.
поддержание мастер данных в нормальном состоянии;
создание базы данных с оптимальным маршрутом движения
информации.
Роли и ответственные:
Решение подготовительных задач проекта – Департамент IT
Решение прикладных задач проекта справочных данных групп
контрагентов, номенклатуры – Департамент группы контроля.
Решение прикладных задач проекта справочных данных группы учета
– Финансовый Департамент.
Решение прикладных задач проекта справочных данных группы WW -
Департамент закупок и Департамент логистики.
Участники проекта - Участники проекта — физические и/или
юридические лица, которые непосредственно вовлечены в реализацию
проекта и чьи интересы могут быть затронуты при осуществлении проекта.
Спонсор и инициатор проекта - Генеральный директор.
Координатор проекта из Центрального Офиса (Франция) - Global
Solution Owner, Global Business Solution Manager, Global Infra Manager, Global
Security Manager.
Стейкхолдерс - Финансовый директор, Директор по логистике,
Директор производства, Директор по закупкам, IT директор, Директор по
маркетингу, Коммерческий директор.
Менеджер проекта - Project Manager.
Команда проекта – Ключевые пользователи департаментов.
Используемые технологии: Разработка базы данных на платформе
MS SQL. Использование облачных сервисов для сбора и первичной
обработки данных. Использование существующих интеграционных
платформ в компании для обеспечения интеграции БД между собой и
65
безопасной передачи данных. Представление to-be системы после внедрения
MDM:
Рис.5. Представление to-be системы мастер базы
Календарный план разработки и внедрения:
Таблица.2. Календарный план внедрения информационной
системы
Внедрение ИС на производстве
Подготовка проекта Чт 01.01.15 Ср 11.02.15
Изучение проблемы Чт 01.01.15 Ср 11.02.15
Сбор и оценка предложений Чт 12.02.15 Вт 24.03.15
Анализ текущих бизнес-процессов Чт 12.02.15 Вт 24.03.15
Изучение документации Чт 12.02.15 Чт 12.02.15
Проведение диагностических интервью Чт 12.02.15 Чт 05.03.15
Подготовка отчета по диагностике Чт 05.03.15 Вт 24.03.15
Анализ текущих бизнес-процессов выполнен Вт 24.03.15 Вт 24.03.15
Определение целей и результатов проекта Вт 24.03.15 Ср 15.04.15
Формирование команды проекта Ср 15.04.15 Пт 17.04.15