Внедрение

Привет, Хабр! Меня зовут Александр. 17 лет в КРОК. В основном занимаюсь разработкой и внедрением заказного ПО, хранилищ данных, решений Big Data для бизнеса и госсектора. Начинал консультантом по внедрению и последние 11 лет работаю менеджером крупных комплексных проектов. А еще я немного пожарный, потому что регулярно помогаю коллегам тушить проектный огонь.

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

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

Про коллаборацию заказчика и соисполнителей

В больших проектах всегда интересно, и часто они преподносят разные челленджи, но тем они интереснее. Мой первый крупный проект (это было внедрение ЕМИАС в поликлиниках Москвы) случился аккурат под новый 2011-12 год, когда у клиента началось активное внедрение новых сервисов в здравоохранении для граждан, сопровождаемое не менее активной информационной кампанией. И мы тоже несли ответственность за развиваемый клиентом бренд ЕМИАС. Огонь возник в условиях готовящейся инфраструктуры и интенсивно развивающегося ПО. Новая функциональность выходила чуть ли не каждую неделю, партнеры готовили СКС, мы доставляли АРМы врачам, устанавливали, подключали, обучали регистраторов заводить расписание, врачей работать с приемом пациентов, запускали и настраивали бизнес-процессы, связанные с внедрением новых сервисов. И все это на фоне ожиданий со стороны правительства Москвы и лозунгов в прессе, что вот новая функциональность, вот новые поликлиники подключили. Таким образом перед нами ставились весьма амбициозные цели и сверх амбициозные сроки.

Как справились с огнем? В этом проекте, который мы развиваем по сей день, очень помогают плотная коллаборация с командой на стороне заказчика и задушенная на корню бюрократия на стороне соисполнителей, обеспечивающих сервисы для функционирования ЕМИАС. Я вспомнил про этот сложный проект, чтобы отметить одну из основных лучших практик в масштабных проектах обязательное наличие квалифицированной команды, обладающей полномочиями оперативного принятия управленческих решений на стороне заказчика. Без этого подобные проекты обречены. Проблемы вроде не работает сетевой порт решались одним звонком коллегам от провайдера, а не отписками заведите обращение, подождите, пока оно пройдет многоступенчатую эскалацию и вообще у нас заказчик не КРОК вовсе обращайтесь через них. Такая слаженная, ориентированная на общий результат целой группы компаний работа, вот лучшая практика и один из важных для меня уроков после этого проекта.

Про коллаборацию заказчика и соисполнителей еще раз

Годы работы в проектах ЕМИАС преподносили нам очень разные вызовы в 2013 у нас была команда внедрения с 700+ консультантами во всех амбулаторно-поликлинических учреждениях Москвы. В 2018 нам надо было найти 100+ консультантов для внедрения лабораторного сервиса ЕМИАС это два месяца собеседований нон-стоп. Но оно того стоило!

Как справились с огнем? Тут, опять же, заказчик помогал в согласовании плана внедрения на стороне объектов внедрения с постепенным наращиванием оборотов и административным ресурсом с оповещением поликлиник, лабораторий. Это еще раз подтверждает тезис необходимости совместной мощной команды не только со стороны исполнителя, но и заказчика. В сложных проектах верно выстроенный процесс взаимодействия и коммуникаций (читай синергия команд обеих сторон процесса) путь к успеху. И вторая мораль этой истории не бояться огня. Глаза боятся (осознав, сколько нужно консультантов и в какой срок, задача казалась нерешаемой в принципе), а руки взяли и сделали! Хоть и собеседования проводили всем миром.

Про ток, или Как снять напряженность клиента

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

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

Про важность работы напрямую с бизнес-заказчиком и решение именно его задачи

Несколько похожая, но вместе с тем иная ситуация была у меня и в другом проекте, где мы для одного из банков делали Big Data систему для построения профиля клиента и оценки рисков при выдаче кредита. В момент подключения меня в проект была не первая фаза, а я не первым РП на стороне исполнителя. Ситуация была схожа с прошлым кейсом непрозрачный процесс разработки для заказчика усугублялась отсутствием четкого ТЗ, ибо такого рода систем в банке, да и на рынке, в то время по сути еще никто не делал. Были первые ласточки в банке Т и банке А, однако готовых решений (да еще на open source) не было. По сути строили с нуля, склеивая кусочный опыт в комплексное решение, попутно синхронизируясь с заказчиком. И еще требования бизнес-заказчиков ловко и резко менялись по ходу представления.

С обеих сторон было сложно и порой проблемно. Со стороны заказчика отсутствие экспертизы и опыта в разработке такого рода систем, хотя ИТ-отдел у них насчитывал несколько сотен специалистов. Кроме того, нас первые два-три месяца фактически не пускали напрямую к бизнес-заказчикам, а работали мы только с ИТ-специалистами, транслировавших нам требования бизнеса. Огня добавляла неготовность команд заказчика, ведущих разработку внутренних систем банка, к оперативной интеграции. Да и вообще к дополнительной нагрузке на системы они были не готовы, а без этого необходимый нашему клиенту сервис было не построить. Для нас системы банка были важнейшими источниками данных для построения и просчета рисковых моделей. С нашей стороны тоже было не все гладко первые несколько месяцев мы велись на постановки, пропущенные через призму ИТ-отдела банка, что сыграло всем в убыток. А еще мы в условиях параллельного развития (постоянного и непрекращающегося) систем банка иногда не успевали за ними, и интеграции ломались или не взлетали в момент деплоя, т.к. система выпустила новый релиз и API поменялось. К счастью, совместно с заказчиком, ситуацию вовремя удалось поймать за хвост.

Как справились с огнем? Здесь применили проведение регулярных встреч (еженедельных) так называемый управляющий комитет проекта. На них присутствовали представители всех смежных отделов и РП разработки систем банка, с которыми нужно было интегрироваться. Вместе мы составили общий роадмап и реперные точки релизов, вместе же постоянно контролировали возможные сдвиги выпуска той или иной функциональности у нас и в системах клиента. Так мы успешно реализовали проект, подтвердили свой профессионализм заказчику и допродали развитие системы еще на 1,5 года.

Про не всемогущий agile

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

А от исполнителя нужно только локальное управление внутри задач и команды, приоритеты и контроль, состав спринтов. Работали по T&M, еженедельно отгружая таймшиты. При этом нам полностью доверили экспертизу и проектирование системы и ее архитектуры, но на входе дали лишь основную суть бизнес-задачи. Детальное исследование и постановка была тоже на нас. Главная проблема была в том, что кроме РП со стороны заказчика в его команде первые два месяца по сути никого не было. И осознал он (мы заметно раньше) эту проблему только через два месяца работы. То есть когда мы, во-первых, не дошли до ожидаемого им результата (напомню, управление на стороне заказчика) и, во-вторых, ему показалось, что выставленный счет слишком высок, несмотря на регулярные таймшиты, которые принимались и фиксированные ставки договор-то был по T&M. Пахло кризисом жанра. Ситуацию усугубляло еще и то, что со стороны заказчика, как и в прошлом кейсе, системы-источники для разрабатываемой системы были не готовы с нами интегрироваться, а заказчик отказывался принимать результаты работ без демо работоспособного решения.

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

Про опытных пожарных

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

Мало огня?

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

Этот кейс был особенно сложен еще и тем, что по ходу проекта (это более 1,5 лет) многие задачи делались от потребности заказчика в моменте, без оглядки на ТЗ. К концу проекта оказалось, что сделана гигантская работа, но не по ТЗ. Хотя многое реально потеряло актуальность за время проекта. А подписались-то мы под ТЗ. И особенности конкретного заказчика были таковы, что невыполненные требования ТЗ к принимаемой системе это путь под откос.

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

Противопожарные меры

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

Со стороны исполнителя важные и проблемные места, которые могут привести к пожару:

1. Отсутствие полной команды управления исполнителя. Для КРОК это два менеджера РП и технический менеджер ТМ, а для комплексных проектов с несколькими командами РП и несколько ТМ;

2. Проблемы коммуникаций не пускают к функциональным заказчикам;

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

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

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

Со стороны клиента:

1. Команда с полномочиями. Крайне важно в проектах построения систем или разработки (и об этом скажет любой учебник, и это прописная истина, в том числе в PMBOK) собрать компетентную команду и наделить людей полномочиями для принятия оперативных управленческих решений и согласования принимаемых проектных решений;

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

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

Про самое важное в проекте для исполнителя про команду

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

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

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

Другим классным инструментом, которым в КРОК по мере возможности пользуюсь тимбилдинги. И это вовсе необязательно замороченное мероприятие типа командной сдачи норм ГТО (хотя и такое было, и это было огонь!). Тут можно и просто собрать команду в неформальной обстановке, пообщаться, поиграть в дженгу и киккер и просто снять таким образом напряжение зума, тимса, вебекса и бесконечных созвонов-созвонов-созвонов Это работает! Я проверил!

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

Вместо заключения

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

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

Вводная часть

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

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

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

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

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

Основная цель безлюдное производство, цифровой завод. Первый шаг навстречу цели - внедрение системы SAP S/4HANA с максимальным использованием стандарта.

Объем проекта

Внедряемые продукты SAP

• SAP S/4HANA

• SAP Fiori LaunchPad (Цифровое окно)

• SAP HCM

• SAP BPC

• SAP MII

• SAP PO

Автоматизируемые процессы

• Бюджетирование

• Финансы

• Снабжение и Сбыт

• Производство и ремонты

• Управление персоналом

• Единое цифровое окно

Особенности работы в удаленном режиме

Обучение ключевых пользователей

Передача знаний на расстоянии

Как эффективно вовлечь пользователей в обучение, никогда не встречаясь с ними? Вопрос, который стал очень актуальным для нашего проекта. Мы не встречались с командой клиента, хотя к моменту обучения и научились узнавать друг друга по голосам. Но решение операционных вопросов и презентации статуса в удаленном режиме отличаются от дистанционного обучения при прочих равных условиях. Нужно удерживать фокус внимания пользователей на протяжении всего тренинга, в нашем случае - это от 2 до 4 часов подряд.

По ходу проведения тренингов мы определили несколько хороших практик по организации и проведению дистанционного обучения по работе в SAP. Их можно объединить в следующие блоки:

Подготовка тренинга:

• Для дистанционного обучения мы использовали инструмент MS Teams, который является аналогом нашумевшего ZOOM, но более корпоративный. Данный инструмент позволяет сделать видеозапись звонка, которую пользователи также в дальнейшем смогут использовать для повторения пройденного материала.

• Для ответов на контрольные вопросы и сбор обратной связи мы использовали MS FORMS. Очень удобный инструмент, который позволяет пользователям сразу увидеть свою оценку и экономит время тренеров на проверку. С его помощью можно создать тест, и даже выгрузить его результаты в формате Excel, что позволяет с легкостью отслеживать статистику и делать сводные таблицы. Плюс - ограничений по количеству форм (тестов) нет.

• Сформировали группы на обучение в размере не более 10 человек. И соответственно рассчитали время тренингов. В случае увеличения численности группы время тренинга увеличивалось.

• На каждый тренинг был назначен 1 основной тренер и 1 помощник, который в процессе тренинга направлял в чат тренинга необходимые ссылки и названия транзакций.

• Лучше заранее проверить Интернет-связь, как на стороне тренеров, так и на стороне пользователей, чтобы не было рассинхронизации голоса и трансляции экрана.

Организация рабочего пространства пользователей:

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

• Чтобы пользователям было удобнее смотреть на экран тренера, где демонстрируется работа в системе, и одновременно выполнять действия в системе, желательно каждому пользователю установить 2 монитора или 1 большой монитор, где можно открыть два окна параллельно.

• Нужно заранее установить все необходимые для обучения программы на компьютеры пользователей, выполнить в них первоначальных вход и запомнить свои учетные данные. Мы столкнулись с тем, что у некоторых пользователей ПО установлено просто не было, в связи с этим было затрачено много времени, на его установку и на решение этой проблемы. Это поможет значительно сэкономить время во время тренинга на осуществление первого входа.

Организация учебного процесса:

• Хорошей практикой стало включение камеры в начале тренинга для приветствия участников и объяснения целей встречи. Так пользователи и тренеры стали узнавать друг друга не только по голосам, но и в лицо.

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

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

• Так как у нас на обучении была взрослая аудитория, то эффективно удерживать внимание получалось примерно в течение 1 1,5 часов. Далее требовалось сделать перерыв на 10-15 минут. Это необходимо учитывать при планировании времени тренинга. Максимальная продолжительность тренинга в течение дня для одной группы обучающихся без потери качества обучения 4 часа.

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

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

Лайфхаки, или наши полученные уроки:

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

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

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

Тестирование функционала системы

Как протестировать функционал системы в удаленном режиме на предприятии, которое еще в процессе строительства?

Для ответа на данный вопрос разберемся, какая ставилась цель, и какие виды тестирования мы применяли на проекте.

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

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

• Функциональное это локальное тестирование возможностей системы. При таком тестировании осуществляется проверка системы в рамках объектов функционального направления;

• Интеграционное позволяет проверить насколько корректно отрабатывает функционал при взаимодействии со смежными функциональными направлениями;

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

1. Организация процесса тестирования:

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

   В качестве основного предполагался удаленный формат проведения тестирования с использованием видео трансляции процесса. В качестве инструмента организации видео конференции был выбран MS Teams.

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

2. Интеграционное:

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

3. Приемочное:

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

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

Концепция раннего старта:

Реально ли внедрить систему так, чтобы какие-то отдельные её части запустились раньше, а какие-то позже? Да!

В ходе проекта было принято решение разбить старт проекта на 3 старта Ранний (Корпоративные функции), промежуточный (Планирование и Бюджетирование) и Основной (Производство, Ремонты, Цифровое окно). Концепция раннего старта подразумевает старт отдельных частей раньше, чем старт всей системы в целом. Такая концепция существенно облегчает миграцию, интеграцию, упрощает склейку отчетности HR и Бухгалтерии в начале финансового года, позволяет сфокусироваться на задачах Корпоративных функций до их стабилизации, а потом уже на Производстве и Ремонтах.

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

Для отдельного направления Цифровое окно применялась методология Scrum.

Для управления развитием системы после раннего старта будет применяться Hybrid Agile.

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