Перевод информационной системы с платформы 1С 7.7 на платформу 1с 8.2/8.3 |
Содержание
Целью данной статьи является анализ подходов к внедрению ИС на платформе 1С, сравнение традиционных подходов и подхода, предлагаемого нами, обсуждение преимуществ и недостатков каждого из них. Сначала определимся с тем, какие же подходы мы будем анализировать и сравнивать. На наш взгляд их всего три, два из которых достаточно широко известны и обсуждались:
Добавим к ним еще один:
Понятно, что для применения последнего подхода, на предприятии уже должна существовать ИС, которую в силу различных причин (какие это причины обсудим в другой раз) решено заменить на новую ИС, поэтому сравнение всех трех подходов будем проводить только для данной ситуации. Теперь определимся с критериями, по которым мы будем определять эффективность того или иного подхода. Здесь ничего нового придумывать не будем, и возьмем элементы тройного ограничения, накладываемого на проект: Первые два параметра должны исходить из принципа - чем меньше вероятность отклонения от первоначального показателя, тем лучше, чем меньше сам показатель, тем лучше. Качество - особый параметр, который должен быть гарантированно выше некоторого «болевого порога». Его оценка носит порой очень субъективный характер, например превышение «болевого порога» влияет на увеличение сроков проекта и превышение его бюджета.
Там где качеством поступиться нельзя наш подход дает максимальный результат! Качество – это соответствие характеристик результата проекта указанным требованиям, а также ожиданиям, которые не указаны, но подразумеваются Заказчиком как само собой разумеющееся. Рассмотрим основные задачи, которые должны быть решены в ходе внедрения новой ИС, риски, возникающие в ходе решения задач, пути их минимизации и то, как они сказываются впоследствии на характеристиках проекта. Сбор требований к системе▲Как правило, должен протекать в два этапа: до заключения договора и после. Причем уже на первом этапе (назовем его экспресс-обследование) необходимо установить время реализации проекта и деньги, за которые он будет реализован. Чаще всего, в обоих случаях, всё, чем располагает Исполнитель - это интервью с ключевыми сотрудниками Заказчика и набор анкет, заполненных рядовыми сотрудниками. В случае с внедрением типового решения - это еще и отзывы о степени соответствия типового функционала потребностям заказчика, которые были получены в ходе демонстрации типового решения.Этой информации явно недостаточно для точной оценки, и правильнее всего дать только оценку сроков и времени реализации следующего этапа, а именно детального сбора и анализа деятельности Заказчика, указать рамки, границы, предположения проекта. Но играются тендеры, Исполнители предлагают “наилучшие” условия…. Так на основании чего же Исполнитель дает свою оценку по срокам и стоимости? Все для чего годны результаты предпроектного анализа - это отнесение проекта к той или иной категории или его оценка по аналогии с уже завершёнными проектами. Для этого необходимо чтобы Исполнитель имел опыт в реализации проектов этой категории, чтобы Клиент был подобен прошлым Клиентам по своему поведению в ходе проекта, чтобы при категоризации проекта не было допущено ошибки и т.д. Список совпадений можно расширять и дальше, но уже понятно, что оценка получается очень приближенной, неточной. Есть еще одна опасность - в ходе предпроектного анализа впасть в заблуждение от кажущейся простоты и одномерности требований, которые высказывает Заказчик. На самом деле Заказчик просто не имеет времени, опыта и желания для детального формирования списка своих потребностей. Из-за этого оценки сроков и бюджета могут быть сильно занижены. Например: при внедрении типового решения может показаться, что всё что нужно будет сделать - это установить типовую систему, провести обучение пользователей, перенести или ввести данные и запустить систему в промышленную эксплуатацию, так как описывая свои потребности, Заказчик говорит в общем о том, что есть в типовой конфигурации, но дьявол, как известно, скрывается в деталях. Способы минимизации вероятности занижения оценок:▲
Третий вариант выполнения принципиально отличается от первых двух тем, что помимо интервьюирования и анкетирования Заказчика проводится комплексный экспресс-анализ его рабочей ИС, которую предполагается заменить в результате проекта. Что и для чего изучается:
Таким образом, мы получаем объективную картину уже на первом этапе проведения анализа, непосредственно изучая требования, которые в наиболее детальной форме зарегистрированы в заменяемой системе. Оценка объема и трудозатрат, а, следовательно, срока реализации и бюджета проекта, получается автоматически, путем анализа собранной информации, и корректируется на основании дополнительных пожеланий Заказчика. При этом стоит особо отметить, что чем больше пожеланий высказывается Заказчиком по изменению имеющегося в системе функционала, тем больше проект переходит во вторую категорию подходов реализации проектов – написании конфигурации с нуля. Рамки проекта размываются, со всеми вытекающими отсюда минусами. Поэтому мы предлагаем разделить проект на две фазы:
Также следует отметить, что переговоры с Заказчиком по обоснованию оценок проекта проходят на более конструктивной основе, т.к. в ходе переговоров Исполнитель и Заказчик говорят на одном языке, обсуждая детальные оценки архитектуры и функционала знакомой ИС, которая длительное время эксплуатируется у Заказчика. Существует вариант снижения стоимости проекта для Заказчика, путем задействования его команды разработчиков, занимающихся поддержкой и развитием имеющегося решения. Поскольку развитие старой системы в ходе проекта будет приостановлено или существенно замедлится, то освободившиеся ресурсы можно перекинуть на новый проект, а поскольку персонал заказчика прекрасно знает функциональные возможности и архитектуру системы - это будет эффективно. Помимо экономии денег на внедрении с помощью такого подхода, достигается и еще одна цель - плавная передача результатов проекта команде Заказчика, которая будет эксплуатировать и дорабатывать ИС после внедрения. Второй этап анализа и сбора требований▲В случае внедрения типового решения, работа на этапе заключается в обучении группы ключевых пользователей возможностям типовой конфигурации и сбора от них замечаний типа «да … но …», после чего выявляются функциональные разрывы между возможностями типового решения и требованиями Заказчика. Разрывы оцениваются, приоритезируются, выдвигаются встречные предложения о реализации требований через возможности типового решения, т.е. выполняется явный или скрытый консалтинг и реинжиниринг бизнес-процессов Заказчика. В случае разработки системы с нуля типового решения нет, но при этом необходимость консалтинга и критического анализа требований Заказчика еще выше, так как противоречивые требования могут создать ситуацию, когда будет разработано заведомо нежизнеспособное решение, т.к в отличие от первого варианта нет типовой конфигурации, методически проработанного решения, на которое мы опираемся. Таким образом, второй этап включает в себя этап консалтинга и реинжиниринга в явном или скрытом виде, несмотря на то, что весьма вероятно Заказчик не предполагал, что в ходе внедрения ИС его будут учить, как ему жить и вести свой уже сложившийся бизнес … аборигены, как известно, съели Кука … На данном этапе при использовании третьего подхода выполнения консалтинга и модификации требований Заказчика не предполагается, т.к. разрабатываем именно то, что уже есть и тесно вошло в организацию работы Заказчика, а то, что не используется, выявлено и уточнено еще на первом этапе анализа. Работа по детальному сбору требований заключается в обучении или самообучении консультантов Исполнителя работе в ИС Заказчика, для того чтобы выявить все моменты взаимодействия не очевидные на первоначальном автоматическом этапе изучения работы ИС и самостоятельно уметь выполнять действия в системе. Это необходимо для выполнения последующего тестирования уже новой ИС, на соответствие поведению старой ИС. Разработка▲На этапе разработки существуют два основных риска По прежнему, это не полные требования к разрабатываемой ИС, либо их неверная интерпретация, выражающаяся в синдроме «да … но …». Следует отметить, что тяжесть ошибок, связанных с не выявленными требованиями растет от этапа к этапу и, именно поэтому, приходится прибегать к частому выпуску промежуточных релизов и их показу будущим пользователям ИС, уделять особое внимание контролю за изменением требований по ходу проекта. Все эти мероприятия и процедуры значительно увеличивают объем работ, выполняемых на проекте, как со стороны Исполнителя, так и со стороны Заказчика. В случае третьего подхода все требования исчерпывающим образом задокументированы в текущей ИС, нужно только правильно извлечь их, анализируя существующий код и структуру метаданных. Конечно, это непросто, но полностью окупается впоследствии и по мере роста опыта у персонала Исполнителя, наработке определенных приемов, выполняется все быстрее и качественнее. Контроль за изменениями требований, также должен присутствовать, но он заключается в отслеживании вносимых изменений в наследуемую конфигурацию уже в ходе проекта и их учете при разработке новой конфигурации. Мы рекомендуем снижать интенсивность внесения изменений в старую конфигурацию в ходе проекта, вносить только изменения, которые нельзя отложить на вторую фазу проекта и соответственно внести их уже в новую ИС. Второй источник рисков - это обычные ошибки, допускаемые в ходе реализации требований программистами. Здесь способ минимизации риска один – тестирование поведения будущей системы с помощью контрольных сценариев. Вероятность ошибок особенно велика в обоих случаях, но по разным причинам, если при написании с нуля это происходит из-за большого объема разрабатываемого кода, то в условиях адаптации типового решения, причиной ошибок является недостаточная очевидность последствий, вносимых в систему изменений. При этом такие ошибки сложнее выявить и тяжесть их может быть очень высокой. При использовании третьего варианта появляется возможность значительно автоматизировать и как следствие существенно увеличить объем выполняемого тестирования, по некоторым участкам доведя его до 100% гарантии отсутствия ошибок в поведении системы. Это достигается за счет особой организации работ по разработке системы и в использовании ряда инструментов, позволяющих выполнять тестирование автоматически. В первую очередь переносится и разрабатывается архитектура будущей системы (структура метаданных).▲Затем выполняется перенос данных из наследуемой ИС, при этом данные переносятся с необходимой для тестирования степенью полноты. Далее реализуются алгоритмы не связанные с интерактивными действиями пользователей, прежде всего- это алгоритмы проведения документов. По мере реализации алгоритмов появляется возможность провести сравнение поведения наследуемой и целевой ИС последовательно перепроводя документы в них обеих . Так как данные после переноса обеих ИС тождественные, то и результаты перепроведения должны совпадать. При этом движения в ИС сравниваются с помощью специально разработанного инструмента, что позволяет практически мгновенно получить отчет о расхождениях и выявить их первопричину. Таким же образом может тестироваться поведение различных обработок, модифицирующих данные, а также отчетов путем сравнения представляемых ими результатов. Особое внимание следует уделять тестированию обмена с другими системами, здесь необходимо следовать тому же принципу - выполнять обмен со сторонними системами между старой и новой ИС, а затем сравнивать результаты. Процедуры, связанные с интерактивными действиями пользователей могут быть разделены на две категории: ▲
Особо необходимо отметить обеспечение требований к производительности и масштабируемости будущей ИС. Как правило, при внедрении типового решения производительность ИС изучается уже постфактум на внедренной и работающей системе. Контроль за эффективностью возлагается на плечи разработчиков внедряемого типового решения, при этом игнорируется тот факт, что внесенные изменения могут серьезным образом ухудшить эффективность типового решения и то, что эффективность протекающих у Заказчика бизнес-процессов может существенно отличаться от типового сценария. При внедрении с нуля возможны варианты реализации прототипа для тестирования производительности, однако и тот и другой подход серьезно страдают из-за отсутствия необходимых для тестирования объемов данных в БД ИС, а также отсутствия базы для сравнения – аналогичной наследуемой ИС, в терминах которой обычно и формулируются требования к будущей ИС: «хотим, чтобы в новой системе работало не 250, а как минимум 400 пользователей, при этом, чтобы среднее время проведения документа вида X было Y» В условиях третьего варианта присутствует и база для сравнения, и предзаполненная тестовыми данными система, и снятые с рабочей системы параметры ее эксплуатации. Все это позволяет сформулировать детальные требования к производительности, разработать сценарии автоматического нагрузочного тестирования, провести тестирование, как в новой, так и в старой системе, сравнить и проанализировать полученные результаты, принять своевременные меры по устранению выявленных недостатков. Таким образом, сходство между целевой и наследуемой системой позволяет реализовать эффективные алгоритмы тестирования новой ИС на соответствие требованиям, в том числе и к производительности, гарантировать отсутствие ошибок в ключевых алгоритмах. После реализации ИС следует этап обучения пользователей работе в ней. Это достаточно сложный и ресурсоемкий этап, объем работ которого прямо пропорционален количеству пользователей и объему функционала, заложенному в системе. Так же дополнительным фактором усложняющим работу по обучению является территориальная распределенность персонала Заказчика. В случае внедрения адаптированного типового решения, объем работ по обучению может быть минимизирован путем обучения персонала в учебных центрах типовому функционалу, но это редко используется, так как в данном случае обучение будет производиться с отрывом от основного места работы, да и если конфигурация в ходе внедрения значительно переработана, а используемый типовой функционал достаточно узок - пользы от такого обучения будет немного. Помимо обучения системе в скрытом или явном виде, проводится последнее перед запуском в промышленную эксплуатацию тестирование ИС, в ходе которого, по прежнему, могут выявляться не только ошибки, но и несоответствия требованиям, что крайне негативно сказывается на сроках и стоимости проекта, значительно увеличивается и то и другое. Для третьего подхода свойственен невысокий, по сравнению с другими двумя подходами, объем работ по обучению, т.к. система для них знакома и вполне узнаваема, как по регламенту работы, так и в значительной степени по организации интерфейса. В детальном тестировании также нет необходимости, т.к. оно было тщательно проведено на предыдущих этапах, путем организации автоматического тестирования. Помимо этого сам процесс пилотного тестирования может быть в значительной степени автоматизирован путем онлайн переноса некоторых данных, вводимых в работающую старую и новую ИС, непосредственно в период реализации пилотного проекта, для того чтобы пользователям не выполнять много рутинной работы, проверка результатов которой не требуется. Ввод в эксплуатацию▲Состоит из следующих этапов:
В третьем случае это маловероятно, так как тестирование выполнялось в полном объеме на реальных данных с реально работающими системами как на этапе внутреннего тестирования Исполнителем, так и на этапе пилотного тестирования Заказчиком;
Промышленная эксплуатация▲Именно здесь цена ошибок возрастает многократно и при выявлении существенных недостатков новой системы, таких как: вновь выявленные несоответствия требований или ожиданий Заказчика поведению системы; постоянные ошибки, приостанавливающие работу системы; низкая производительность системы - могут заставить Заказчика принять решение вплоть до отказа в эксплуатации новой системы и возврате на старую ИС. Все во многом будет зависеть от того, сможет ли Заказчик смириться с имеющимися недостатками и как-то продолжать работать с ней до устранения наиболее критичных замечаний. Иногда, и довольно часто такой процесс превращается в перманентный, т.е. уже работающая во внештатном режиме ИС дорабатывается спешно и бессистемно длительное время. В третьем варианте Заказчик должен получить систему аналогичную по функционалу имеющейся, с незначительными доработками, и освоившись с ней, инициировать второй этап проекта по ее эволюционному изменению под новые требования, таким образом, полученная на первом этапе система должна стать базовой для последующего расширения функционала. Следует также отметить достаточно большой объем работ на этапе разработки, т.к. система разрабатывается, по сути, с нуля. Если внимательно рассмотреть данный аспект, то становится понятно, что объем работ по кодированию не превышает объема работ при разработке с нуля и скорее всего даже ниже, т.к. работы по разработке системы не содержат различных отбрасываемых прототипов и многократно переработанных участков системы, которые неизбежны при написании системы с нуля, хотя бы средней степени сложности. Что касается внедрения типового решения, то малый объем кодирования зачастую лишь только кажущийся, сложность доработки и внесения изменений в типовое решение, как правило, значительно выше, чем при написании с нуля. И это все еще не учитывает тот факт, что традиционные подходы в значительной степени подвержены рискам, связанным с неточно сформулированными и не полностью выявленными требованиями, отсутствием механизмов автоматического тестирования, что приводит к многократной переработке одного и того же кода, и как следствие кратному увеличению объема работ, связанного с разработкой. Безусловно, этот подход, несмотря на свои преимущества, имеет и одно фундаментальное ограничение, а именно у Заказчика должна существовать система, которую он хотел бы портировать на новую платформу в качестве базовой для последующего ее расширения и адаптации с использованием новых возможностей, которые предоставляет ему новая платформа. Когда это так, то выбор очевиден. Когда все-таки риски настолько велики, то лучше пойти по другому пути предпочесть третий вариант, несмотря на некоторые издержки и неэффективность применения данного подхода. Для этого проведем классификацию ИС и выявим те признаки, которые косвенно могут указывать на то, что стоит серьезно задуматься над возможностью применения данного варианта или некоторых его элементов. Классификация ИС, которые могут существовать на предприятии: ▲
Классифицировать можно и дальше, но и этого вполне достаточно для того чтобы описать в каких комбинациях вариантов наш подход, т.е. третий вариант наиболее эффективен.
Если у Вас сильно модифицированная типовая конфигурация или нетиповая конфигурация, разработанная с нуля, это уже веский повод задуматься о третьем варианте. Если требования к надежности работы системы высоки, а значит система задействована в оперативном контуре управления деятельностью предприятия, а также время на ввод в эксплуатацию жестко ограничено, это также веский повод внимательно рассмотреть возможность третьего подхода. Дополнительными факторами в пользу третьего варианта являются большое количество территориально распределенных пользователей, высокие требования к производительности системы, наличие большого числа систем, между которыми выполняется обмен, а также наличие своей собственной команды разработчиков, занимающихся поддержкой и развитием планируемой к замене ИС, чем то ведь они занимаются, а значит, Ваши потребности далеко не полностью удовлетворяются поставщиком типовых решений и как следствие скорее всего не будут удовлетворены и с помощью внедрения аналогичного решения на новой платформе. ▲ |