И снится вам сон: будто вы должны пройти по канату, натянутому над пропастью, без страховки и без тренировки
Вы не помните, как ступили на этот канат, не помните, как удалось пройти половину пути, но нутром чуете, что оставшуюся часть пути пройти не сможете. А назад уже нельзя, туда ровно столько же, что и на другую сторону. Вы замираете, с ужасом пытаетесь держать равновесие, ноги подкашиваются, голова кружится, шаг вперёд, вы теряете равновесие и начинаете падать, судорожно пытаясь схватиться то ли за проплывающий мимо канат, то ли за воздух и летите вниз. И тут вы просыпаетесь в холодном поту и понимаете, что на какой-то момент отключились прямо на совещании по переходу на новую систему. «Мы не можем пройти без страховки», — бормочете вы. «Что с вами?», — спрашивают вас коллеги. «Вы побледнели, может открыть окно?». «Мы не сможем без страховки, мы упадём!»
Не знаю, насколько литературно мне удалось описать то, что я сейчас наблюдаю, вопрос не в этом, а в страховке. Даже самый неопытный канатоходец сможет перебраться по канату на другую сторону, если есть страховка. Как говорится, «хоть чучелкой, хоть тушкой». Того, кто панически боится высоты, в конце концов, просто перетащат, завязав глаза и связав руки и ноги. Всё дело в страховке! Нет, нет, я не сошёл с ума и не помешался на трансерфинге, но без страховки нельзя 🙂 🙂 🙂 🙂 🙂
А теперь применительно к «нашим баранам». Я прошёл через десятки проектов по внедрению Scala/iScala, которые не были просто проектами внедрения системы «с нуля». Это были проекты по переходу со старой системы на Scala или iScala. И через чуть меньшее количество проектов по переходу со Scala/iScala на другую систему, когда у компании менялся собственник и, как следствие, IT стандарты. И знаете, какая часть проекта самая важная?
Создание работающего прототипа новой системы?
Нет.
Настройка параметров или программирование?
Нет.
Тестирование?
О, да!!!
Если мы вспомним правило Парето, то оно в данной ситуации звучит следующим образом: «20% — программирование, 80% — тестирование»
Лучшие практики при переходе на новую систему подразумевают комплексное тестирование, а не профанацию в виде тестирования отдельных функций
Что значит «комплексное»? Это, когда прослеживаются результаты последовательности действий, как в реальной жизни. Ну, например, из корпоративной системы (или из ERP системы вашего поставщика) приходит сообщение об отгрузке машины с заказанной продукцией. Это сообщение автоматически создаёт уже в вашей системе заказ на закупку (если он ещё не был создан) и накладную на оприходование товаров на транзитный склад. Далее уже с транзитного склада поступает электронное сообщение о растаможке, которое в вашей системе будет выглядеть как перемещение с транзитного склада на склад продаж, но ваша система даёт вам контроль над этим процессом, оно не происходит автоматически, а ждёт, когда вы разрешите это сделать, ведь перед этим бухгалтер должен включить в стоимость товара все необходимые таможенные пошлины и процедуры, добавить стоимость транспортировки и т.п., а часть продукции списывается на сертификационные тесты. Складской комплекс помимо сообщения о перемещении также производит маркировку поступившей продукции и отправляет эту информацию в систему отслеживания маркированного товара, но без цены (эта информация недоступна складу), а ваша система добавляет сведения о цене. После этого происходит процедура контроля качества, создание заказов на продажу, отгрузка покупателю, отправка ему электронных документов через систему ЭДО, включая такие, какие не предусмотрены стандартно, а некоторым покупателям дополнительные сообщения через SFTP. А еще нужно убедиться, что все корпоративные отчёты о продажах сформируются корректно.
Это читать-то утомительно. А представляете, что значит качественно это протестировать? С отслеживанием как бухгалтерской информации, как то, правильные бухгалтерские счета, цена, себестоимость, так и другой не менее важной информации, как то номера партий, номера ГТД, дата изготовления и сроки годности.
И если это тестировать кусками, вы никогда не сможете понять, правильно система работает или нет. Самый трудоёмкий, но и в то же время один из самых надёжных способов комплексного тестирования — это параллельный ввод. Не всем такое нравится из-за его трудоёмкости, но на многих крупных проектах, в которых мне удалось участвовать и где компании очень серьёзно подходили к вопросу оценки результата готовности системы к эксплуатации, это было реализовано. Параллельный ввод не обязательно подразумевает работу «день в день», это может быть и воспроизведение в новой системе операций за определённый «исторический» период, например, в процессе тестирования в сентябре вводятся все операции за июнь, а перед этим вводятся все остатки на конец мая. Результаты из двух систем, старой и новой сравниваются. Результаты не обязательно должны совпадать, если при этом мы понимаем, почему они не совпадают и принимаем это. По результатам такого тестирования выявляются ошибки, как в работе новой системы, так и в работе пользователей. Ошибки в работе системы исправляют и повторно тестируют, а пользователи приобретают опыт и уже не будут на каждом шагу делать ошибки, когда придёт час перейти на новую систему. Самые «продвинутые» компании специально на этот период нанимают временных работников, чтобы разгрузить ключевых пользователей или обращаются к услугам аутсорсинговых/аутстаффинговых компаний.
А что насчёт страховки? Так это она самая и есть. А без этой страховки будет так, как в том страшном сне 🙂
