Перевод информационной системы с платформы 1С 7.7 на платформу 1с 8.2/8.3   

Содержание

• Сбор требований к системе
  • Способы минимизации вероятности занижения оценок
• Второй этап анализа и сбора требований
• Разработка
  • Процедуры, связанные с интерактивными действиями пользователей
• Ввод в эксплуатацию
• Промышленная эксплуатация
  • Классификация ИС

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

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

• Внедрение типовой конфигурации
• Разработка конфигурации «с нуля»

Добавим к ним еще один:

• Разработка конфигурации 1С на основании детального изучения и максимально подробного переноса функционала наследуемой ИС, т.е. той (или тех, если их несколько) которую мы заменяем в ходе внедрения новой ИС.

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

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

Первые два параметра должны исходить из принципа - чем меньше вероятность отклонения от первоначального показателя, тем лучше, чем меньше сам показатель, тем лучше. Качество - особый параметр, который должен быть гарантированно выше некоторого «болевого порога». Его оценка носит порой очень субъективный характер, например превышение «болевого порога» влияет на увеличение сроков проекта и превышение его бюджета.

• Соблюдение сроков – просто время, минимизация сроков, если повезет;
• Реализация в рамках бюджета – просто деньги, минимизация бюджета, если повезет;
• Результат надлежащего качества – наиболее интересная и наименее понятная характеристика проекта, максимизация качества, если повезет.

Там где качеством поступиться нельзя наш подход дает максимальный результат!

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

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

Сбор требований к системе▲

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

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

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

Способы минимизации вероятности занижения оценок:▲

• Вообще не давать таких оценок. Но, как было сказано выше - Заказчик уже на этапе тендерного отбора, при выборе Исполнителя желает получить от него оценки основных параметров проекта с точностью как минимум +/- 15% от фактической;
• Давать оценки с запасом, т.е. просто на всякий случай, увеличивая сроки и бюджеты. Но при этом есть и другие участники тендера - оптимисты, которые могут пойти на риск и заложить меньше, при этом ни один из участников не сможет обосновать свою правоту, т.к. апелляции к своему прошлому опыту вряд ли Заказчика удовлетворит, а значит, решение будет приниматься на основании условий, предлагаемых Исполнителем, т.е. того, кто быстрее и дешевле, а также на основании его репутации, т.е. выберут того, кто вызвал больше доверия;
• Давать оценку с достаточно большим риском ошибиться, т.е. заведомо оптимистичную, в надежде на то, что в ходе проекта удастся изменить элементы тройного ограничения, увеличить бюджет и сроки, сократить перечень требований к результатам проекта;
• Выполнять уже на первом этапе очень тщательный анализ Заказчика и требований, которые он предъявляет к системе, но это не приемлемо как с финансовой точки зрения, т.к. эту работу приходится делать бесплатно, так и по причине нехватки времени на выполнение такой детальной работы из-за сжатых сроков проведения тендерного отбора. Кстати, возможно это и правильно, т.к. ценность такого анализа для результатов самого проекта достаточно сомнительна, потому что это обследование необходимо в первую очередь для того, чтобы дать оценки сроков и бюджетов с высокой степенью точности, а для последующей работы полученные результаты могут напрямую и не пригодиться. Что толку, например, от того что мы точно узнаем, что подсистема бюджетирования типовой конфигурации полностью соответствует требованиям Заказчика и ее нет необходимости модифицировать? В ходе проекта это и так станет известно, т.е. мы потратим деньги на то чтобы узнать что-то раньше, чем могли бы, если бы никаких денег не тратили, конечно, иногда это полезно, но чаще нет.

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

Что и для чего изучается:

1. Частота использования того или иного функционала с помощью специальной системы мониторинга, для того чтобы выявить наиболее часто используемые подсистемы, характер их использования и отсечь от дальнейшего рассмотрения тот функционал, который в системе присутствует, но Заказчиком не используется и приоритезировать оставшийся функционал по степени критичности его реализации;
2. Структура конфигурации, внешних отчетов и обработок, а также хранимых процедур и прочего функционала, реализованного вне платформы 1С - это необходимо для оценки сроков реализации и бюджета проекта;
3. Временные характеристики поведения ИС, такие как: время проведения документов, выполнения отчетов, частота блокировок дедлоков и пр. - это необходимо для выявления узких мест в системе Заказчика и формирования требований к производительности, и к программно-аппаратной платформе будущей системы;
4. Данные в системе, как дополнительный источник об интенсивности протекающих в ИС Заказчика бизнес-процессов, а также для формирования требований к производительности и масштабируемости будущей системы, переносу данных из наследуемой системы в целевую.

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

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

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

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

Второй этап анализа и сбора требований▲

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

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

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

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

Разработка▲

На этапе разработки существуют два основных риска

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

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

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

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

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

В первую очередь переносится и разрабатывается архитектура будущей системы (структура метаданных).▲

Затем выполняется перенос данных из наследуемой ИС, при этом данные переносятся с необходимой для тестирования степенью полноты.

Далее реализуются алгоритмы не связанные с интерактивными действиями пользователей, прежде всего- это алгоритмы проведения документов.

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

Особое внимание следует уделять тестированию обмена с другими системами, здесь необходимо следовать тому же принципу - выполнять обмен со сторонними системами между старой и новой ИС, а затем сравнивать результаты.

Процедуры, связанные с интерактивными действиями пользователей могут быть разделены на две категории: ▲

• обеспечивающие - наиболее важные из них могут быть протестированы по аналогии с подходом, приведенным выше: на вход функций и процедур в обеих ИС подается одинаковый набор параметров, а выходы сравниваются автоматически;
• обработчики событий нажатия на контролы в формах – они, как правило, тестируются интерактивно консультантами по мере реализации функционала, и пользователями в ходе пилотного проекта уже на заключительной стадии.

Особо необходимо отметить обеспечение требований к производительности и масштабируемости будущей ИС. Как правило, при внедрении типового решения производительность ИС изучается уже постфактум на внедренной и работающей системе. Контроль за эффективностью возлагается на плечи разработчиков внедряемого типового решения, при этом игнорируется тот факт, что внесенные изменения могут серьезным образом ухудшить эффективность типового решения и то, что эффективность протекающих у Заказчика бизнес-процессов может существенно отличаться от типового сценария. При внедрении с нуля возможны варианты реализации прототипа для тестирования производительности, однако и тот и другой подход серьезно страдают из-за отсутствия необходимых для тестирования объемов данных в БД ИС, а также отсутствия базы для сравнения – аналогичной наследуемой ИС, в терминах которой обычно и формулируются требования к будущей ИС: «хотим, чтобы в новой системе работало не 250, а как минимум 400 пользователей, при этом, чтобы среднее время проведения документа вида X было Y»

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

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

После реализации ИС следует этап обучения пользователей работе в ней.

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

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

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

Ввод в эксплуатацию▲

Состоит из следующих этапов:

• этапа развертывания системы - здесь следует еще раз обратить внимание на проблемы, которые могут возникнуть с интеграцией новой ИС с другими ИС, с которыми она должна обмениваться информацией.

В третьем случае это маловероятно, так как тестирование выполнялось в полном объеме на реальных данных с реально работающими системами как на этапе внутреннего тестирования Исполнителем, так и на этапе пилотного тестирования Заказчиком;

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

Промышленная эксплуатация▲

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

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

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

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

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

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

Классификация ИС, которые могут существовать на предприятии: ▲

1. По времени между событием или управляющим воздействием и его регистрацией/созданием в ИС:
   • Оперативные – регистрация в момент возникновения события или управляющего воздействия, что накладывает жесткое ограничение по времени простоя системы из-за возникших ошибок;
   • Неоперативные – регистрация постфактум, либо управляющее воздействие, исполнение которого может быть отложено и не должно выполняться немедленно, жестких ограничений на время простоя нет.
2. По роли в БП организации:
   • Управляющие – организуют и поддерживают работу БП организации; если это ключевые БП, то, как правило, в большинстве случаев без этих ИС организация работать не сможет, т.е. простой в работе ИС это простой в работе компании в целом или ее отдельного участка, т.е. наличие этого признака усиливает признак в пункте 1.1;
   • Регистрирующие – просто отражают и фиксируют факты хозяйственной деятельности компании для последующего анализа.
3. По потребителям информации, фактически по инициаторам тех изменений, которые вносятся в ИС:
   • Управленческие – внутренние потребители компании; характеризуются своим разнообразием, так как подходы к ведению бизнеса и сам бизнес в достаточной степени различны и не похожи между собой, как правило, такие системы либо разрабатываются с нуля, либо за годы эксплуатации типовая конфигурация сильно модифицируется;
   • Регламентированные - внешние потребители, как правило, контролирующие органы; характеризуются тем, что функционал продиктован требованиями этих потребителей и поэтому единообразен по отношению к большому количеству компаний. В системе существует часть, которая должна обновляться с использованием типовой конфигурации, что значительно сдерживает ее модификацию, а поскольку пользователями ее во многом является не сам бизнес, а контролирующие организации, изменения в части регламентированного учета не могут быть принципиально необходимыми.
4. По степени охвата БП организации:
   • Корпоративные – охватывают большинство ключевых БП компании. Как правило, это сложная и развитая по своему функционалу система, играющая ключевую роль для Заказчика. Простой или неверная работа такой системы может вызвать паралич в деятельности всего предприятия;
   • Местные – как правило автоматизируют какой-то один БП; достаточно простые системы и соответственно не имеют для бизнеса такого принципиального значения как корпоративные.
5. По количеству пользователей:
   • Крупные - от 100; основные проблемы, вызываемые большим количеством пользователей - это высокие требования к производительности системы и большой объем работ по обучению пользователей функционалу новой ИС;
   • Средние - от 40 до 100; здесь тоже, что и в крупных, но степень проблем меньше. Проблемы, связанные с производительностью могут отсутствовать;
   • Малые - до 40.
6. По количеству БД:
   • Распределенные (чаще территориально, но бывает разделение по функциональному признаку) – усложняет архитектуру системы, процесс проведения обучения, перенос данных из старой ИС в новую;
   • Монолитные.
7. По взаимодействию с другими ИС:
   • Интегрированные – обмениваются информацией с другими ИС компании, которые в той или иной степени накладывают свой отпечаток на данную ИС, например, являются одним из основных источников серьезных переработок типовых решений, усложняют процесс разработки;
   • Самостоятельные – обмена нет, либо он незначителен.
8. По степени соответствия наследуемой системы типовому 1С решению:
   • Cистема написана с нуля – типичный кандидат на третий вариант перехода, т.к. внедрение типового решения потребует серьезного консалтинга и реинжиниринга БП Заказчика, а написание с нуля новой системы, без оглядки на старую, возможно только при условии того, что имеющееся решение для бизнеса не подходит и должно быть заменено на принципиально новое;
   • Модифицированная - степень модификации, конечно, может быть разной, но здесь нужно разбираться детально в том, что именно из используемого функционала типовой подверглось адаптации под потребности организации. Если из используемого ф-ла, изменению/расширению подверглось более 50% то можно считать, что система сильно модифицирована. Возможность эффективного применения третьего подхода также очень высока, т.к. внедрение типового решения потребует либо повторного выполнения существенной переработки уже новой ИС, либо существенного реинжиниринга БП Заказчика, единственным соображением в пользу внедрения типового решения является как раз желание Заказчика изменить свои БП под типовые, имеющиеся в предлагаемом типовом решении;
   • Типовая или почти типовая - изменений нет или они носят косметический характер; здесь удобнее всего перейти на аналог типовой конфигурации на новой платформе, так как идеология предлагаемого решения будет совпадать с имеющимся и процедура переноса данных в значительной степени уже отлажена на предыдущих внедрениях, факторами в пользу третьего варианта могут быть узость задействованного функционала типового решения и высокие требования к производительности.

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

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