Мы хотели бы поделиться опытом: того, с чем мы сталкиваемся, и того, что мы кровью и потом наработали с нашими заказчиками – у нас достаточно крупные и проблематичные заказчики – типа ГазпромНефти и Почты России.
То, о чем я буду рассказывать, по большей части актуально для крупных структур, когда у вас есть головная компания и филиалы, ДЗО, которые обладают различной степенью самостоятельности и различным видением одних и тех же процессов, чем сильно усложняют процесс внедрения.
Статья написана по материалам доклада, прочитанного автором на первой конференции инфостарта 2012 года. Она опубликована в журнале Инфостарта №1.
Общие этапы внедрения автоматизированных систем
Общие этапы внедрения автоматизированных систем общеизвестны (обычный PMBOK):
Анализируем требования того, что нужно заказчику, затем проектируем, разрабатываем, тестируем – развертываем у заказчика систему и отдаем ее в эксплуатацию.
Как правило – если проект большой – сделать все это за одну итерацию практически невозможно, потому как у нас на этапе анализа функциональных требований поступает масса изменений. Пользователи не представляют себе, что они получат на выходе через какое-то время – то есть изначальное ТЗ на 400 листов согласовывается по формальному признаку – мало кто способен вникнуть в суть того, что там написано.
На этапе разработки, как правило, пропускаются сроки – не получается реализовать требования за приемлемое (отведенное под это) время, поэтому время, отведенное под этап тестирования обычно «съедается» - пропускается по условному предположению, что разработчики и так все правильно сделали. А потом – при внедрении изменений у заказчика (при запуске какого-нибудь большого блока УПП), естественно, пользователи боятся нового функционала и всячески сопротивляются.
Технология быстрых результатов
Для решения этих проблем 1С в кризис придумала так называемую «технологию быстрых результатов». На Западе уже давно существует аналог - технология «Гибкие методики разработки» - AGILE. (www.agilemanifesto.org)
- Люди и взаимодействия важнее, чем процессы и инструменты
- Работающий код важнее совершенной документации
- Сотрудничество с заказчиком важнее контрактных обязательств
- Реакция на изменения важнее следования плану.
Главная идея гибких методик разработки заключается в том, что нам важнее удовлетворенность заказчика, а не следование подписанным планам-графикам, утвержденным техническим заданиям и т.д. То есть, главное для заказчика – получить результат и важнее с ним эффективно работать, нежели выполнять просто контрактные обязательства.
Agile предлагает зациклить разработку - сделать ее непрерывной и многоитерационной, чтобы заканчивая какой-то блок, мы тут же начинали другой.
В итоге у нас разработка получается непрерывной в течение практически всего проекта – мы делаем какие-то маленькие функциональные блоки, реализуем их – сдаем в эксплуатацию, и тут же принимаемся за следующие.
Если посмотреть на структуру этой итерационной доработки (тут приведена схема из какой-то презентации по AGILE), то что мы увидим здесь:
- первая большая колонка – это общие функциональные требования, которые у нас есть к системе. Мы на каждую итерацию выделяем, либо согласовываем с заказчиком, какой блок мы делаем (это может быть отдельный бизнес-процесс, отдельный функциональный блок), берем его в разработку, в течение какого-то не очень продолжительного периода (2-4 недели) – его реализуем.
- Обязательно каждый день должно производиться обсуждение результатов работы – грубо говоря, каждый день вся проектная команда утром должна на 15 минут собраться вместе (т.н. stand up meeting) – стоя, не разглагольствовать, быстренько все обсудить. Говорим, что мы сделали за вчерашний день, что мы готовы сделать за сегодняшний, планируем свои действия, чтобы более оперативно управлять процессом.
- По окончании этого спринта – этой итерации – мы проводим обязательно демонстрацию для заказчика, чтобы заказчик уже увидел, что мы действительно что-то сделали, а не просто полгода сидели и непонятно что разрабатывали.
- По окончании демонстрации обязательно проводится так называемая ретроспектива – мы должны оглянуться назад и пересмотреть, что мы сделали качественно и наоборот, что у нас не получилось, сделать для себя какие-то отметки, запланировать устранение этих проблем далее, и, может быть – принять меры в своей проектной команде – поменять разработчиков или сделать что-то еще.
Этапы внедрения системы
Далее мне бы хотелось рассмотреть подробнее этапы внедрения системы – какие моменты можно учитывать на этих этапах.
На этапе анализа функциональных требований, как правило, большие компании любят привлекать консалтеров – McCance или еще каких-нибудь крутых – но практика показывает, что в российских реалиях ничего хорошего из их работы не выходит, те бумажки, которые они разрабатывают – их можно просто выкинуть и все, получается, деньги потеряны просто так.
Создание центров компетенции
Часто удачным бывает решение выделять так называемые «Центры компетенции» внутри заказчика – если компания большая – десятки тысяч человек – можно выделить из их числа 5-10 человек, которые будут понимать бизнес-процессы по какой-то области – коммерческий учет, бухгалтерский учет, налоговый учет, управленческий учет. И именно эти люди будут разрабатывать эту методологию, непосредственно заниматься тестированием и оказывать консультации пользователям, когда они начинают реализацию этой методологии применять. С поддержкой «Центров компетенций» перенос требований бизнеса на будущую автоматизированную систему будет осуществлен наиболее эффективно.
При поблочном внедрении – концепция «Пилот – адаптация – тираж»
Поскольку мы понимаем, что большую систему внедрить практически невозможно (перестраивать бизнес под информационное пространство никто сразу не согласится), также необходимо договориться по поводу концепции «Пилот – адаптация – тираж». По сути, - это та же самая «Технология быстрых результатов», только немного в другую сторону направленная. «Технология быстрых результатов» - это внедрение поблочное, а под технологией «Пилот – адаптация – тираж» подразумевается, что мы охватываем разный организационный объем нашего заказчика в течение какого-то времени. Сначала внедряем этот блок в каких-то одних ДЗО, в каких-то одних филиалах, потом в других и так далее… Это позволяет учитывать опыт небольших групп пользователей заказчика и в дальнейшем устранять какие-то замечания и не нарываться на проблемы.
Создание проектного офиса
Также важным моментом на этапе анализа функциональных требований (в самом начале проекта) является создание проектного офиса. Это особенно важно, если автоматизация комплексная – внедряется коммерческий учет, управленческий учет (например – по классической схеме – внедряется УПП, ЗУП, Консолидация данных и Система управления НСИ). В задачи проектного офиса будет входить курирование команд разработчиков, которые у вас будут заниматься непосредственно разработкой системы. Даже если подрядчик один – все равно люди разные – тяжело заставить людей говорить друг с другом о том, что один сделал документ в коммерческом учете, значит, в бухгалтерском учете тоже нужно что-то поправить. А когда будет создан орган, это контролирующий – это позволит повысить качество работы
Методы и инструменты контроля проектного офиса:
- контроль соблюдения сроков проекта в соответствии с планом-графиком;
- контроль расходования трудозатрат по проекту;
- контроль над изменениями в проекте;
- контроль качества управления, а также повышение квалификации руководителей проектов;
- контроль KPI задействованных сотрудников – замена сотрудников при необходимости;
- контроль над документированием проекта;
Выбор оборудования
На этапе выбора оборудования – когда мы рекомендуем заказчику, что же ему нужно купить в итоге, есть очень много любителей гнаться за объемами – набрать дисков по 2 ТБ, в сервер воткнуть процессоров по 4 штуки на сервер. Однако, те же HP-шные сервера – если вы возьмете 2-х процессорную машину с топовыми процессорами и 4-х процессорную машину, то у вас 2-х процессорная получится мощнее, потому процессоры будут с более высокой тактовой частотой.
С дисками – то же самое – лучше взять меньший объем, зато не SATA, а SAS диски. А лучше SSD. Дороже – да, зато скорость обмена данными будет достаточно высокая, и вы не упретесь в производительность.
Как это оборудование вообще выбрать?
Проще всего попытаться воссоздать будущую нагрузку на том оборудовании, которое вы собираетесь выбрать для своей системы (попросить у кого-то такое оборудование и запустить на нем, например, стандартный нагрузочный тест для УПП, сделать какую-нибудь групповую обработку по Консолидации данных, в ЗУП-е нагенерировать тысячу сотрудников, и попытаться на них рассчитать зарплату).
Это позволит более объективно посмотреть, как ведет себя оборудование и понять узкие места.
Где взять это оборудование?
HP достаточно ходовой товар, и сервиса по его тестированию вроде нет. Однако партнеры вендоров, производящих сервера IBM или ORACLE очень часто дают эти сервера потестировать.
Вы можете обратиться к партнеру IBM. Он вам выделит для тестирования и систему хранения данных отличную и сервера POWER 7, вы сможете увидеть непосредственно в работе это железо и потом уже принять решение – покупать его или нет. У IBM есть такая отличная структура, называется «Центр инноваций IBM». Она на бесплатной основе может предоставлять оборудование для тестирования, то есть, если вы сомневаетесь в выборе какой-то СУБД, сомневаетесь в выборе какого-то оборудования, и потенциально склоняетесь при этом к покупке оборудования IBM, то вы можете обратиться в «Центр инноваций». Вам бесплатно предоставят тестовый стенд с необходимыми СУБД. Могут даже ORACLE поставить, SQL Server поставить, вы сможете уже конкретно посмотреть, как на них себя поведет система. Еще один интересный момент – они иногда проводят бесплатное обучение по DB2 (правда, на английском языке).
Другой вариант - арендовать на время мощный сервер в облаках Amazon или Azure.
Этап разработки прототипа
На этапе разработки прототипа:
- не нужно разрабатывать конфигурации «с нуля». Часто бывает, что крупные заказчики хотят какие-то особенные подсистемы, которые ни одно типовое решение не покрывает, и разработчикам приходится что-то делать полностью «с нуля». Лучше взять за основу БСП и применить его в качестве «конструктора с базовой функциональностью». Берете БСП и тут же начинаете реализовывать вашу прикладную бизнес-логику. Используете уже готовые подсистемы ролевой модели, подсистемы управления пользователями – то, без чего не обойтись.
- Также важно определить ключевые операции изначально, даже до согласования с заказчиком вы понимаете, какие ключевые операции важны для бизнеса, попытаться встроить замеры производительности из БСП, чтобы вы могли на каждом этапе отслеживать динамику изменения этих показателей. Чтобы уже на этапе разработки вы видели, в какие целевые значения мы укладываемся.
- Для автоматизации нагрузочного тестирования по ключевым операциям обязательно нужно использовать подсистему «Тест-центр». Это достаточно простой инструмент. Есть обучающее видео http://infostart.ru/public/152161/ о том, как встраивать Тест-центр в конфигурацию, как разрабатывать простые тесты и смотреть результаты их выполнения. Несмотря на то, что КИП, в состав которого входит Тест-центр, стоит 84000 рублей, эта конфигурация того стоит. Можно потратиться и получить удобный инструмент, нежели каждый раз изобретать велосипед и пытаться писать нагрузочные тесты.
- Нужно попытаться хотя бы частично автоматизировать функциональное тестирование. Это должно быть реализовано на этапе разработки прототипа. Однако позже – на этапе сопровождения системы это очень пригодится.
- Важно привлекать Экспертов по технологическим вопросам. Не обязательно это должен быть человек, у которого есть такой сертификат. Этот человек должен хотя бы сходить на обучение. Достаточно просто вникнуть в то, что рассказывают на трехдневном тренинге по сертификации на статус «Эксперта по технологическим вопросам», прослушать, какие вопросы задаются при сдаче этого экзамена и по результатам этого тренинга мышление немного меняется – люди хотят «свернуть горы». Правда практика немного не стыкуется с теорией и пыл проходит, но – все равно, знания экспертов по технологическим вопросам на этапе разработки прототипа очень важны
- Важно также генерировать достаточные массивы данных для проверки механизмов. Если вы знаете, что у заказчика 12000 сотрудников, то при разработке тестировочной базы количество тестируемых данных также должно быть соответствующим
- Придерживаться рекомендаций по стандартам разработки 1С. (давайте уважать друг друга – при разработке в команде это важно)
- Процесс разработки должен производиться в той же СУБД и ОС, которые будут у заказчика. Не используйте разработку в файловых базах. Если заказчик собирается использовать серверный вариант – для разработки прототипа также обязательно используйте серверную базу. Нет денег на СУБД - используйте бесплатные альтернативы. Для DB2 есть прекрасный вариант – IBM выпустила новую бесплатную версию DB2 Express-C 10.1, у которой повышен объем допустимой оперативной памяти до 4-х Гб. Если мы сравним ее с ORACLE и MSSQL Server (с их аналогичными бесплатными версиями Express-C), то там этот объем памяти равен 1Гб.
Обязательно необходимо всегда использовать управляемый режим блокировки данных и использовать разделение итогов по регистрам (использование управляемого режима блокировки данных дает существенный прирост параллельности работы системы при большом числе одновременно работающих пользователей)
Функциональное тестирование
Расскажу поподробнее о функциональном тестировании:
1С нам сделала огромный подарок тем, что реализовала объектную модель для функционального тестирования. Понятно, что она доступна только для управляемого интерфейса и только для 8.3. Но – на управляемом интерфейсе у нас уже УТ11 и БП3.0. Это уже большой объем функциональности, которую достаточно часто внедряют. Вам никто не мешает вести разработку (работу) в 8.2 – а для тестирования создать отдельную базу, сконвертированную на 8.3, посадить на нее отдельного консультанта, который вам достаточно легко набьет эти тесты (запишет сценарии, сконвертирует эти сценарии в программный код, вы вставите в эти сценарии свои процедуры проверки). При выпуске релизов вы сможете в пакетном режиме запустить свои тесты и проверить работоспособность ключевых механизмов. Это позволит очень сильно сэкономить время в период авральных обновлений.
Выбор СУБД для разработки прототипа
Опять-таки, подробнее о выборе СУБД для разработки прототипа:
Преимущества использования управляемого режима блокировки данных и разделения итогов по регистрам накопления
И диаграмма прироста производительности в случае использования управляемого режима блокировки данных и разделения итогов по регистрам накопления в нагрузочном тесте на 500-600 одновременно работающих пользователей.
Регистрация ошибок платформы
Следующий спорный момент – это регистрация ошибок платформы. Регистрация ошибок конфигурации не интересует – мы все профессионалы, устранить ошибки в конфигурациях мы можем. А в платформе, к сожалению, не можем.
К сожалению, разработчики не любят регистрировать ошибки, нужно указывать регистрационный номер и т.д. Но есть одна уловка. Вы воссоздаете ошибку в тестовом релизе, для которого существует специальная линия поддержки тестовых релизов платформы.
Там не требуется регистрационных номеров, там сидит адекватный человек, который оперативно отвечает. В течение последнего года мы таким образом зарегистрировали порядка 30 ошибок – это эффективно способствовало их реальному устранению.
Запуск в промышленную эксплуатацию
Следующий этап – запуск в промышленную эксплуатацию
- На этапе запуска в промышленную эксплуатацию необходимо настроить мониторинг загруженности оборудования. Основные параметры (загруженность дисков, загруженность памяти, загруженность процессоров). Это не требует времени и усилий на настройку, но потом – постфактум, когда вы будете разбираться с проблемами, когда вы будете передавать данные разработчику, это позволит своевременно делать определенные выводы
- Необходимо настроить в целом мониторинг доступности самих серверов с помощью специализированных средств. Например, бесплатные opensource-решения – zabbix, nagios
Этап сопровождения
На этапе сопровождения системы ключевыми моментами является:
- Проводить нагрузочное и функциональное тестирование перед выпуском каждого релиза. То, что вы разработали на этапе разработки прототипа, вам здесь очень поможет.
- Необходимо настроить периодический сбор данных краткого технологического журнала и системных представлений СУБД, их консолидацию и анализ. Использовать для постоянного мониторинга ЦУП будет тяжело, потому как он нагружает систему, долго анализирует – полезность полученной информации будет сомнительна. Если же вы будете просто мониторить тяжелые запросы, а потом как-то их агрегировать – будет гораздо эффективнее. Я выкладывал программку на .NET, которая позволяет в многопоточном режиме разбирать технологический журнал, засовывая полученные данные в табличку на MS SQL Server (http://infostart.ru/public/117023/ ). Из этой таблички вы простыми запросами можете увидеть, например, Топ-100 наиболее тяжелых, увидеть их планы выполнения запросов и принять какие-то меры.
- ЦУП поможет при выявлении проблем в продуктивной базе под существенной нагрузкой
- Настроить и контролировать выполнение регламентных операций СУБД. Возможно, для контроля того, что регламентные операции СУБД выполняются, будут необходимы дополнительные доработки.
- Контролировать версии платформы и релизов конфигураций при большой распределенной сети информационных баз. Если у вас распределенная структура, бывает, что в центре 8.2.16, в регионе на первом уровне 8.2.15, а в филиале 8.2.13. В итоге у вас функциональность может по-разному работать, что, конечно, будет вызывать проблемы. Проще сделать в решении какую-нибудь табличку, чтобы система автоматически сконсолидировала информацию о том, какие версии платформы где используются.
Обеспечить качественную обратную связь с конечными пользователями. Имеется в виду не первая линия поддержки (документ не проводится, мышка сломалась, система не открывается). Имеется в виду вторая линия поддержки – сопровождение внедренной системы. Если вы используете для этого Word, Excel, Outlook (консолидируете информацию в почте) – то это неэффективно – вы не можете сделать ни выборку данных, ни предоставить отчетность заказчику по трудозатратам. В нашей компании мы для этих целей разработали так называемую «Система управления инцидентами».
«Система управления инцидентами»
Этот программный продукт позволяет консолидировать наш опыт и в удобном управляемом интерфейсе предоставлять пользователям возможность вводить в систему инциденты, просматривать и комментировать инциденты, возникающие в других регионах.
Эффект получился очень большой – мы дали возможность пользователям одного региона комментировать инциденты пользователей другого региона - по факту давать им советы, помогать друг другу. Мы снизили нагрузку на себя за счет того, что заказчик сам себе помогает. Регистрируют инцидент в удобной форме – прикрепляют скриншоты, прикрепляют необходимые файлы, ссылки.
Мы сделали обработку по бизнес-процессу для того, чтобы четко понимать, сколько трудозатрат было на каждый инцидент, понимать, какие этапы он прошел. Схема бизнес-процесса отрисовывается непосредственно в режиме «Предприятие».
Начать дискуссию