Внедрение Oracle Retail 13 в топ 10 мировой розницы
Хочу рассказать о своем опыте внедрения Oracle Retail 13 в топ 10 мировой розницы своего сегмента в России. Я был внештатным сотрудником, приглашенным из Берлина.Сначала я думал, что все дело в резком увеличении объемов работы, и штатная служба поддержки не справляется.Оказалось, не все так просто![BR]На второй линии поддержки возраст заявок доходил до 7 месяцев. Инструкции для второй линии были нерабочими.Поскольку система была для меня новая я начал прорабатывать старые заявки. Правила работы были следующие: прилетела заявка, скопировать ее содержимое, вставить в инструкцию. Если нашелся ответ, то запускаем скрипты, для соответствующего интерфейса. Самое интересное было в том, что для большинства заявок не было прописано каких-либо действий в инструкции.Следовательно, данные заявки были направлены фирме-внедренцу через третий уровень поддержки (главное, не забыть поставить в копию начальника отдела и руководителя проекта внедрения). Интересно, что фирма-внедренец предусмотрела в инструкции определенные скрипты для контроля товародвижения, и внесла их в инструкцию. К сожалению, это были неправильные скрипты (системный уровень противоречил бизнес-слою).
Пример: скрипт, показывающий однозначность движения товара, в выборке показывал 4 направления. Началась игра в пинг-понг с фирмой-внедренцем за правильные скрипты. Если выделить основные проблемы, то это:1) отсутствие скриптов,2) отсутствие прохождения данных через шину (RIB). То есть данные складкой системы (данные по товару, уже разгруженному в магазине) со склада не проходили через шину. Было в инструкции предложено взять номер сообщения, вставить его в веб-интерфейс шины и нажать кнопку. Беда была в том, что таких сообщений было несколько десятков тысяч. Я посчитал необходимое время-19 человеко-дней. И это по одному из 113 интерфейсов. Меня это не устраивало. Я запросил скрипт у третьего уровня поддержки. Используя данный скрипт, я прогрузил данные через шину за 15 минут, и сразу закрыл 40 заявок. После этого я провел аудит документации на предмет автоматизации и нашел несколько мест для автоматизации, что в последствие было и сделано. Большую проблему представлял ситуация, когда удалили несколько тысяч артикулов в торговом бэк-офисе (Oracle Retail 13), но во всех 30 фронт-офисных системах данный товар остался. Была поставлена задача администратору фронт-офисной на перевод данных артикулов в выводимый сегмент и дальнейшего его списания. Списанный товар перестал попадать в управленческий учет. Сложность вызывало то, что был нарушен принцип независимости SOA-один интерфейс-один бизнес процесс.[BR]Примерно было 130 интерфейсов, и на каждом из них было до 12 шагов. Начиная со второго шага было много разночтений, т.е. отсутствовала однозначность для принятия решения службой поддержки. Началась затяжная переписка с фирмой-внедренцем ПО (не забывая, естественно, ставить в копию руководство). Большую проблему представляли письмо в поддержку не на рабочих языках проекта (испанский, португальский). Приходило до 40 заявок каждый день, 5 минут на обработку каждой, 3 месяца-итого несколько человеко -дней чужой работы. Мы могли просто закрыть заявки, но тогда мы бы подставили ребят из тех стран. Мной был разработан регламент по работе с иноязычными заявками, написана база знаний по ключевым словам. Чужие заявки перестали поступать к нам. Теперь можно было работать, потому что остались только наши заявки. Занялся проверкой актуальности скриптов: что-то мне подсказывало,что это необходимо сделать, и подсказывало правильно. Общая ошибка: никто не проводил аудит трансляции при переходе с бизнес-слоя на системный уровень. Пришлось запрашивать схемы бизнес-процессов у бизнеса и сверять актуальной бизнес-логикой. Поскольку после каждого нового шага приходилось делать аудит, то на одном интерфейсе актуализировать данные у фирмы разработчика приходилось несколько раз за рабочий день.[BR]Поскольку несколько интерфейсов зависели друг от друга это приходилось учитывать при работе.[BR]Теперь несколько слов о сервис-менеджменте. Поскольку ситуация была запущенная, я начал делать заявки с конца, то есть самые старые, если не было срочных. При таком подходе два плюса: начинаешь понимать актуальность заявки и узнавать способы проверить это, второе-сокращается средний возраст заявки. Кроме того, можно узнать сотрудника, который сможет проконсультировать.С начала апреля был устойчивый рост ежедневного количества заявок, с конца мая с получением скриптов для автоматизации, количество заявок стало снижаться. Особое место занимали случаи изменения бизнес-процессов. То есть я нашел проблемное место. Подсветил его фирме-внедренцу, запросил скрипты для его решения и решил-идеальная и невозможная ситуация. Не было четкого понимания, где моя зона ответственности а где нет. Запросил и руководителя проекта детализацию раздела- разбил раздел на несколько разделов, чтобы персонифицировать зоны ответственности. Подключили дэшборды начальнику на каждый раздел TTMS, чтобы он видел средний возраст заявки и принимал управленческие решения. Разделов было много, по ним были совещания, когда резко возрастал средний возраст заявки какого-либо раздела. Через пять месяцев внедрения количество заявок резко сократилось, однако, взаимодействие системы было далеко от идеала. Я начал разбирать разделы TTMS нашего отдела в системе, но не нашел ничего нового не нашел.
Для очистки совести начал смотреть чужие разделы, благо, что у меня был доступ администратора. Меня очень удивило, что заявки, которые функционально должны быть на нашем отделе, были на другом отделе . Таких заявок было от четверти до трети от общего количества. В это же время (после пяти месяцев проекта) один из сотрудников отдела стал сервис-менеджером. Мы вместе решили данную проблему. Я перевел эти заявки в нужные разделе. Количество заявок резко сократилось. Остались заявки за границами моей экспертизы[BR]По итогам работы суточное количество заявок сократилось с 1100 до 200, доля заявок по Oracle Retail сократилось с 75% до 15%. Проведен аудит всех бизнес-процессов по поддержке программного продукта.