Сопровождение WMS: кто в ответе за сбой?

Дмитрий Перов, эксперт журнала «Логистика и управление»

В журнале «Логистика и управление» № 3 был опубликован анализ причин не слишком большой заинтересованности поставщиков решений класса WMS в сопровождении своих инсталляций. Теперь рассмотрим возможные виды технической поддержки, которые могут быть оказаны, их необходимость и востребованность на рынке WMS.

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

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

Приоритеты запросов

В договорах и регламентах сопровождения поставщики ПО предлагают поочередно выделить приоритеты, правда, в контексте постановки запросов к службе сопровождения. Для рынка WMS это неприемлемо. Наш «самолет» при полном отказе, в отличие от их «танка», попросту разобьется. Я предлагаю рассматривать приоритеты с другой точки зрения: что резервировать, что оставить своей IT-службе, что должно быть элементом гарантии, а что частью собственно сопровождения, в том числе и платного.

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

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

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

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

Элементы гарантии

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

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

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

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

Снижение производительности

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

Проблемы снижения производительности – это отдельный разговор. Любые системы при длительном использовании начинают «подтормаживать», растет объем базы данных, и запросы начинают выполняться медленнее. При продаже разработчики всегда заявляют требования к аппаратным средствам. Эти требования должны выдвигаться осознанно, и случай, если потребитель выполнил условия, а уровень быстродействия низок, является гарантийным. Поставщик может ограничивать в договоре максимальный объем хранимых данных. Это связано с тем, что многие бизнесмены стремятся хранить всю историю перемещений товаров по всему складу за весь период работы программы в рабочей базе «на всякий случай». Объективной необходимости в этом нет. Если вы торгуете золотыми слитками, то объем базы будет небольшим.

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

Приоритет 4 – единственный, который попадает под определение сопровождения, вернее – никак не попадает под гарантийные обязательства. Есть ли необходимость в таком сопровождении? Есть, но это точно не абонентское обслуживание, ни одна из услуг не прогнозируема. Рамочный договор на сопровождение просто удобнее, чем постоянное заключение отдельных договоров на какую-либо услугу, но объем работ и оплата могут и должны определяться в каждом случае отдельно.

Что касается услуг по установке и настройке программного обеспечения, то они могут иметь место, если речь идет о:
а) настройке ПО-радиотерминалов;
б) настройке рабочих станций в клиент-серверной модели, но WMS c такой архитектурой не так много, большинство – трехуровневые;
в) создании резервного сервера уже в процессе эксплуатации и настройки схемы резервирования.

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

Обновления системы

Человек, работающий в области эксплуатации систем, должен быть максимально консервативен. Экспериментаторство – это удел разработчиков. Делать обновление за обновлением не стоит. В них исправляются не ваши проблемы, но иногда при таком исправлении создаются «ваши». Если обновление делалось специально как ответ на ваш запрос об исправлении ошибки, тогда – да. В остальных случаях администратор обязан наложить вето. Поставщику выгоднее держать всех своих пользователей на одной и той же версии, так меньше затраты на сопровождение. Но ведь это его проблемы. Вот пусть и делает обновление бесплатно и гарантирует при этом, что все возникающие при этом ошибки он тоже устранит. Вопросы по использованию ПО – это бесплатная форма сопровождения де-факто на рынке WMS. За советы денег не берут, если, конечно, ответ на ваш вопрос не заставит весь офис поставщика неделю искать на него ответ.

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

Мелко нашинкованные услуги

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

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

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

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

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

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

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

Дмитрий Перов, эксперт журнала «Логистика и управление»

https://www.lobanov-logist.ru/library/all_articles/56171/

дата: 00.00.0000 00:00:00 просмотров: 2108

рейтинг:

(Голосов: 1, Рейтинг: 5)