Моделирование 1с что это
Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 1С специалистов, является мнение что проектирование системы - это лишние трудозатраты. Я бы сказал, оно не безосновательно. Многие из задач при внедрении систем являются довольно стандартными и требуют лишь трудозатрат на разработку. Очень часто не создается новых механизмов и инструментов, а лишь «дотачиваются» существующие, притом под нужды заказчика, которые регулярно меняются.
В этом случае формальный процесс проектирования навряд ли имеет смысл. Речь идет именно о формализации процесса, т.к. сам процесс проектирования является неотъемлемой частью разработки и конечно будет присутствовать, пусть даже только в голове разработчика.
А когда проектирование имеет смысл:
- Есть общая стратегия компании, и развитие ИТ систем – часть этой стратегии.
- Есть понимание от менеджмента какие задачи требуется решить посредством внедрения/развития информационной системы.
- Есть формальное понимание/описание бизнес процессов компании, или планируется его создание.
Собственно, все начинается со стратегии. Инструментарий для создания стратегии компании редко бывает специализированным. Это скорее нечто, что должно быть в голове у топ менеджера. Далее строится модель бизнес процессов (которая должна присутствовать для достижения стратегических целей). Здесь уже в ход идут инструменты моделирования – ARIS , Business Studio . И только после этого речь заходит о модели ИТ процессов. У «продвинутых» западных вендоров для этого есть специализированные средства – У SAP интегрированный ARIS , у IBM – RUP , у Microsoft – MSF , интегрированная в Visual Studio . Вот и у 1С появился собственный инструмент – 1С:СППР.
Теперь возникает второй вопрос: «А как на практике используется 1С:СППР»? В данном случае могу рассказать только о своей личной практике. К сожалению, она может не совпадать с тем, для чего в 1С планировали 1С:СППР. В моей практике 1С:СППР использовался для следующих задач:
Из рисунка, пожалуй, все понятно – в систему заносится информация исходя из текущих моделей бизнес процессов – проектируется модель системы: процессы и функции, которые декомпозируются до уровня метаданных и алгоритмов. Далее генерируются документы – спецификации на разработку, проектные решения и даже пользовательская документация.
Стоит отметить, что в данном случае речь идет не столько об 1С:СППР, сколько о системе, которая была разработана на ее основе, путем внесения достаточно существенных модификаций. Дело в том, что первая версия 1С:СППР, когда нам требовался подобный инструмент, не отвечала нашим требованиям, да и вообще вряд ли могла отвечать чьим либо требованиям:
Но это уже было кое-что, за что можно «зацепиться» и разработать полнофункциональный инструмент. К счастью, 1С вели разработки 1С:СППР параллельно нашей, и большую часть из того, что приходилось добавлять на текущий момент времени уже реализовано в типовой конфигурации.
В итоге, все функции, которые, на мой взгляд, должны лечь на 1С:СППР можно разбить на следующие 4 части:
1) Функции моделирования
a. Модель системы, связь с моделью БП (в разных нотациях)
b. Связь модели системы с метаданными и алгоритмами 1С
c. Интеграция со средами моделирования
2) Функции коллективной работы
a. Работа с требованиям
b. Работа с ошибками
3) Функции документирования
a. Связь документации с моделью
b. Экспорт документации в 1С и Word
4) Функции организации разработки и тестирования
a. Спецификации и задачи на разработку
b. Результаты тестирования и отработки ошибок
В типовой 1С:СППР очень хорошо реализован блок (1), за исключением того, что хотелось бы конечно иметь возможность представлять модель в разных нотациях. Нам была ближе EPC , в 1С:СППР реализована только IDEF 0.
Функции коллективной работы в текущей версии реализованы в полном объеме, на мой взгляд конечно, чаще всего это необходимо при работе с ошибками и требованиями.
С документированием возникают уже проблемы. Основной функционал, которого не хватает 1С:СППР – экспорт в Word . Ведь итогом работы проектировщика должна быть спецификация на разработку (ТЗ/ЧТЗ – кто как называет). А спецификация - это нечто, что человек должен иметь возможность прочитать; то есть текстовый файл. Опять же, вордовским файлом должна оформляться документация по системе и проектная документация. Но традиционно 1С не сильно любит интегрироваться с продуктами Microsoft Office . Это противоречит принципам кроссплатформенности, делает решение зависимым от внешних приложений и существенно увеличивает сложность разработки.
Функционала для организации разработки и тестирования в 1 C :СППР просто не существует. Хотя не понятно почему. Редко встретишь опытного разработчика, который хоть раз в своей жизни не написал бы систему учета задач. Если ориентироваться на тот же SAP – в Solution Manager есть как функционал проектирования так и полноценный Service Desk .
Собственно, данный функционал относительно СППР был доработан – основные доработки 1С:СППР касались вывода в Word и создания системы учета задач.
Теперь более подробно рассмотрим функционал типовой 1С:СППР новой версии:
Итак, относительно первой версии появилось много чего интересного:
1) Нормальная работа с метаданными – загрузка метаданных непосредственно из конфигурации, представление, дополнительные свойства объектов метаданных. На разработку подобного функционала в первой версии мы потратили значительное количество времени.
2) Моделирование системы в нотации IDEF . 1С много затратили на разработку данного функционала. Действительно существенный шаг вперед, но, как писал выше, для нас оказалась привычнее и удобнее нотация EPC . Она в 1С:СППР, к сожалению, не реализована.
3) Сбор требований. Функционал очень нужный на проектах.
4) ER модель метаданных. Первое впечатление было «мечта студента». Если кто-то писал диплом по 1С это бы существенно помогло. На самом деле функционал очень полезен и в повседневной рабочей практике. Даже просто загрузив в 1С:СППР механизмы типового прикладного решения построив ER диаграмму по нужным объектам можно гораздо быстрее и проще разобраться как работает тот или иной механизм. О пользе подобных диаграмм при составлении спецификаций можно и не говорить. За данную возможность можно сказать «большое спасибо».
5) Работа с ошибками, тоже очень нужный, но достаточно простой механизм системы.
6) Есть даже инструментарий для написания справочной информации. Он не очень мощный и удобный больше вследствие ограниченности встроенного в 1С редактора текстов, но привязка справки к метаданным и экспорт справочных файлов очень удобный функционал, которым теперь можно пользоваться.
Как у нас используется 1С:СППР. Вполне возможно наш случай – не типичный сценарий, как его планировали 1С. Общая схема выглядит примерно следующим образом:
Скорее всего в типовом сценарии использования, предусмотренным 1С, не подразумевается работа в системе тестировщиков и разработчиков. Так же не предусмотрено детальное описание алгоритмов.
Итак, что мы получаем от использования 1С:СППР:
1) Разработчики отделены от проектировщиков. Best Practice из SAP welcome . Наверное, это правильно, но для того, чтобы это было возможно, система просто необходима. В то же время, при наличии такой системы мы можем сказать, что практически любой разработчик способен выполнять работы практически по любой задаче. Это «открывает двери». Например сегодня у вас 3 разработчика, а завтра может стать 30… т.е. варианты для привлечения внешних подрядчиков не ограничены.
2) Генерация проектной документации. В нашем случае ее просто тома. Представьте к примеру задачу описать все метаданные УПП… 1С:СППР просто в десятки раз упрощает данный процесс.
3) Учет задач – когда он интегрирован это очень удобно. Разработчик может сразу видеть все по назначенной задаче. При необходимости может подняться «уровнем выше» чтобы что-то понять/уточнить для себя. Как проектировщик так и разработчик могут оценивать трудозатраты на разработку и согласовывать оценки. Разработчик может писать вопросы к спецификациями и оперативно наблюдать изменения в них
4) Весь проект есть в системе. По каждому объекту метаданных вы можете отследить когда, для чего и зачем он был сделан.
Мы уже пошли в чем то дальше чем 1С:СППР в развитии системы, но есть вещи которых нахватает как в нашей системе так и в типовой 1С:СППР:
1) Управление изменениями. Что поменялось, кто согласовал? На что повлияет это изменение. Очень важный момент, конечно сложный в реализации, но управление изменениями сразу вывело бы систему на новый уровень и повысило бы ее полезность.
2) Связь с хранилищем конфигурации. Конечно последнего этапа в цепочке не хватает немного. Если бы в системе можно было получить информацию по какому заданию/спецификации была эта разработка?
3) Интеграции с ARIS/Business Studio. К сожалению, встроенные средства 1С существенно проигрывают специализированным в плане удобства и функциональности для постраения диаграмм EPC / IDEF .
Итого, 1С:СППР очень функциональный и полезный в практике продукт. Очевидно, что 1С движется в правильном направлении. Может что-то еще не так, чего-то не хватает, поэтому с нетерпением ждем развития системы, ну или дорабатываем сами.
Первый шаг к внедрению компания-заказчик должна сделать самостоятельно. На рисунке показано уравнение ценности при принятии решения об автоматизации.
С этого шага начинается активное взаимодействие двух сторон – Исполнителя и Заказчика. Исполнитель – это:
- носитель знаний о типовых программных продуктах
- лучших практиках
- методах автоматизации.
Заказчик – это носитель информации о специфике и преимуществах компании:
- структуре
- процессах
- потоках информации
- требованиях к результату
- проблемах и противоречиях.
Заказчик со своей командой, во многом, превращается в непосредственного участника проекта, и движется к освоению новой системы. Исполнитель должен «освоить» процессы и специфику компании-заказчика, чтобы адекватно переложить их в новую систему. И это происходит не мгновенно, требует времени и итераций.
Состояние компании-заказчика перед внедрением
Состояние компании-заказчика, в которой созрела потребность внедрения современной программной системы, может характеризоваться «букетом» факторов:
- Разнообразие программных средств разных вендоров, кусочно покрывающих различные бизнесы и участки учета. В них вложено много сил и средств. Это итог поспевания за потребностями бизнеса и новыми технологиями.
- «Груз» старых систем, как тормоз для развития бизнеса, реализации новых задач. 20% сделанных доработок обеспечивает уникальность, специфику и преимущества компании. Их надо сохранить. Остальные 80 % доработок сделаны бессистемно, не используются или используются «раз в год». От них надо избавится.
- Внутренние противоречия между бизнес-руководителями подразделений по поводу замены/внедрения современных приложений, вплоть до неприятия новых систем.
- Отсутствие единого понимания путей перехода на новый уровень автоматизации, большая начальная неопределенность и множество открытых вопросов, незнание принципов проектного и консультационного внедрения ПО, большая погруженность в собственные процессы м неготовность к переменам.
В тоже время, ставятся новые бизнес-задачи, но развитие и обновление старых систем затруднено, трудоемко и выливается в «кипучую», неэффективную и затратную деятельность ИТ-служб. А воз и ныне там. Знакомая картина.
Со стороны Исполнителя работу с Заказчиком первым проводит аккаунт менеджер. Задачей аккаунт менеджера как раз является:
- Определение реального состояния компании по этим и другим вопросам.
- Работа с инициаторами потребности в части ориентации компании-заказчика в генерации оптимальных шагов и снятия у них части неопределенности и вопросов.
- Подготовка к следующему шагу взаимодействия с подключением специалистов по программным продуктам.
Сделаем акцент на пункте 4. А именно: "движению компании-заказчика к внедрению обычно препятствует большая начальная неопределенность и множество открытых вопросов" по деталям внедрения, отсутствие в компаниях такого опыта, отсутствие знаний по современным программным продуктам и их эффективному применению.
Где и как Заказчику ответить на эти вопросы? Что могут предложить Исполнители?
Типовые этапы автоматизации. Моделирование
Типовые программные продукты 1С (ERP, УТ-11, Управление холдингом и др.) разрабатываются так, чтобы с помощью настроек и гибкому использованию функционала удовлетворить максимальное количество компаний. Но программы усложняются, включают в себя множество методик, внедрение блоков-подсистем требует особых компетенций.
"Примеряя" типовой продукт 1С к компании-заказчика – по каждому блоку, процессу, функции, операции, структуре данных – специалист-аналитик Исполнителя вырабатывает приемлемые решения:
- решений может не быть или решение может быть частичным – тогда потребуется доработка типового функционала;
- решений может быть несколько – необходимо выбрать оптимальное – доработка не требуется;
- в некоторых случаях типовое решение может быть, но требует изменения процессов учета в компании и т.д.
Отработку решений в типовой системе 1С мы называем моделированием или разработкой решений. В силу своей значимости, оно занимает особое место среди этапов автоматизации на базе типовых систем, символизирует перенос основной трудоемкости работ по внедрению с программирования на моделирование.
Основных обязательных этапов автоматизация три – результаты одного этапа являются входами следующего этапа:
- ЭтапI.Экспресс-обследование/обследование процессов и систем заказчика. Для крупных компаний и холдинговых структур обязательно проведение обследования каждого направления деятельности и/или каждой компании холдинга.
- ЭтапII.Моделирование/наложение и выработка решений с подготовкой прототипа системы и написанием документа Концептуальный дизайн/проект. В нем описываются все принятые решения на типовом функционале. Если требуются доработки, то дополнительно создается документ Техническое задание.
Моделирование ведётся по блокам, короткими итерациями при наличии активной взаимосвязи с Заказчиком: создание модели – демонстрация – корректировка модели.
Ценность моделирования для Заказчика
По мере продвижения по этапам снимается неопределенность, вопросы реализации приобретают конкретное наполнение. Работы по этапам I и II фактически являются аудитом внедрения 1С в компании-заказчика.
Такой аудит имеет особую ценность для Заказчика, т.е. обеспечивает ему следующие важные преимущества и контроль над внедрением:
- предварительную оценка внедрения, т.е. уяснение этапов внедрения, их содержания, сроков и стоимости, своего участия в проекте автоматизации.
- оценку применимости продуктов 1С к специфическим процессам компании и масштабы доработок;
- получение предварительных решений своих задач в типовых системах 1С; а именно, получение демо-базы со сквозными примерами и её описания в виде документа Концептуальный дизайн/проект.
- получение обучения с учетом специфики компании;
- получение опыта и компетенций к будущему внедрению и снятие многих неопределенностей;
- по результатам аудита внедрения Заказчик может принять решение о переходе с проектного на консультационное самостоятельное внедрение!
Для Исполнителя этапы I (Экспресс-обследование/обследование) и II (Моделирование/наложение и выработка решений) просто необходимы, т.к. на них принимаются основные решения как по реализации, так и рассчитываются объемы, сроки и стоимость работ.
Другая задача Исполнителя – построить план-график работ. Часть работ по этапам может распараллеливаться, выделяться в отдельные итерации/релизы в зависимости от методологии управления разработкой (проектом). Исполнитель должен грамотно структурировать цели/задачи, принять правильные решения по итерациям/релизам, обеспечить продуктивность команды разработки для правильной и быстрой реализации итераций/релизов, обеспечить петлю обратной связи с Заказчиком для дальнейшей разработки итераций/релизов.
В качестве дополнения, к статье прилагается презентация "Сущность и ценность моделирования, как разработки решений в сложных типовых системах 1С".
- работает ли концептуальная модель?
- соответствует ли она поставленным техническим- или бизнес-требованиям?
- какие ограничения и границы модели?
- уязвимости, ограничения, экономика проекта и др.
Должен ли владелец бизнеса ответить на те же вопросы при запуске новой системы 1С:Предприятие (1С ERP, КА, УТ и др.) да и всего остального ? Однозначно. Функциональное моделирование как раз для этого и предназначено.
Предлагаю оглавление по документу ФМ:
- Описание бизнес-процессов предприятия (As is/To be).
- Выбор решений программного и аппаратного обеспечений.
- Насколько соответствует типовое решение техническим требованиям и бизнесу?
- Какая допустимая нагрузка на систему / подсистемы?
- Какие условия информационной безопасности?
- Обзор текущей инфраструктуры.
- Какие функциональные разрывы между системой и бизнес-процессами и способы их устранения?
Вернёмся к математике, к формуле нормального распределения, график которого имеет следующий вид:
Основные задачи «1С:Корпоративного инструментального пакета 8»:
Это больше чем необходимо на ФМ, но крайне важно на средних и крупных проектах (внедрения по технологиям ТБР и ТКВ). Для внедрения ТСВ (Технология стандартного внедрения) допускается не делать нагрузочное тестирование.
Результатом функционального моделирования должен стать:
- одноимённый документ, в котором описаны бизнес-процессы, поведения системы, результаты тестирования и требуемые функциональные доработки,
- база(ы) данных.
Несколько моделей предназначены для варианта нескольких кандидатов типовых/отраслевых решений Для принятия правильного решения требуется предоставить сравнительную характеристику, например SWOT-анализ.
Рабочая папка наполняется большим количеством файлов, которые созданы в работе следующим программным обеспечением:
Сегодня мы подробно расскажем о методике, которую ежедневно применяем при внедрении программных продукт 1С. В качестве примера возьмем ПП "1С:ERP Управление предприятием".
КАСКАДНАЯ МОДЕЛЬ ВЕДЕНИЯ ПРОЕКТА
При внедрении 1С специалисты компании используют каскадную модель ведения проекта, которая включает в себя следующие этапы:
- Предпроектное обследование. Формулировка первоначальной информации о проекте, целей автоматизации, выбор программного продукта, разработка плана проекта.
- Моделирование основных процессов. Разработка модели работы в системе, выявление необходимых доработок, формирование контрольного примера и отчета по результатам моделирования.
- Формирование технического проекта, разработка. Доработка по техническому проекту (кодирование), тестирование, сдача/приемка работ на контрольном примере.
- Разработка сценария формирования начальных данных. Определение регламента, ответственных и сроков сверки данных, подготовка данных для переноса, предварительный перенос данных.
- Первоначальная настройка программного продукта 1С. Настройка параметров учета, настройка пользователей и прав, первоначальная настройка информационной базы.
- Разработка инструкций и обучение пользователей. Подготовка пользователей для дальнейшей работы в системе, может включать в себя прохождение курсов, индивидуальное обучение, разработка инструкций.
- Опытная эксплуатация проекта. Подготовка к опытной эксплуатации, тестирование, исправление выявленных недочетов, подготовка к промышленной эксплуатации.
- Окончательный перенос данных. Утверждение даты перехода, подготовка и окончательный перенос данных к дате перехода.
- Промышленная эксплуатация проекта. Начало работы в новой системе, поддержка работы пользователей.
Рассмотрим каждый этап подробнее.
ЭТАП 1. ПРЕДПРОЕКТНОЕ ОБСЛЕДОВАНИЕ
- изучение базовых бизнес-процессов заказчика, формализация бизнес-процессов, описание "как есть" и "как будет", выяснение основных проблем, которые заказчик хотел бы решить с помощью системы автоматизации;
- выявление уникальных конкурентных преимуществ заказчика;
- сбор требований к документообороту;
- виды и формы отчетности;
- уточнение бюджета проекта и сроков его реализации с учетом всех полученных данных;
- выработка рекомендаций по выбору методов реализации проекта.
Возможные варианты проведения:
1) Анкетирование
- заказчику предлагается заполнить анкеты в электронном виде;
- анкеты предназначены для уточнения основных бизнес-процессов и параметров ведения учета, выявления потребностей;
- анкеты разделены по блокам учета, могут заполняться несколькими ответственными лицами одновременно;
- на основании предоставленной информации формируются предложения по методам реализации проекта, а также дальнейшим этапам внедрения.
2) Сбор требований
- включает в себя первый этап — Анкетирование;
- со стороны заказчика и исполнителя формируется рабочая группа проекта;
- в ходе обсуждения в рамках рабочей группы проекта выявляются потребности и пожелания заказчика;
- производится анализ текущего состояния информационных баз, оборудования, серверов, сетевого оборудования («как есть»);
- анализируются входные данные и потоки информации, а также требуемые выходные данные и формы;
- формируются предложения по методам реализации проекта;
- фиксируются рамки проекта, планируются этапы внедрения;
- производится укрупненная оценка бюджета проекта.
3) Отчет о предпроектном обследовании
Включает в себя Этап 1.1. Анкетирование, а также Этап 1.2. Сбор требований.
Основным результатом этапа является итоговый отчет о выполненных работах, согласованный и подписанный исполнителем.
Основные составляющие отчета:
- краткое описание существующих бизнес-процессов заказчика;
- перечень основных задач, которые необходимо решить с помощью системы автоматизации;
- оценка бизнес-процессов заказчика и рекомендации по изменению или оптимизации работы подразделений с учетом преимуществ, предоставляемых системой;
- уникальные конкурентные преимущества заказчика, которые следует обязательно учесть при внедрении системы;
- краткое описание документооборота в автоматизируемых подразделениях и требований к аналитике;
- оценка возможных рисков при реализации проекта и определение мер, необходимых для минимизации их влияния;
- описание пожеланий заказчика, которые не могут быть реализованы в предлагаемой системе управления и потребуют доработки, оценка времени и стоимости подобной доработки;
- перечень оборудования для реализации проекта автоматизации;
- предложение по реализации проекта с обоснованием предлагаемого варианта, задание необходимого для заказчика количества автоматизированных рабочих мест и уточнение бюджета проекта;
- план-график, включающий в себя в том числе согласованный список ответственных лиц (как со стороны заказчика, так и от исполнителя), зоны их ответственности и базовый регламент взаимодействия между ними.
ЭТАП 2. МОДЕЛИРОВАНИЕ ОСНОВНЫХ ПРОЦЕССОВ
Основные составляющие этапа:
- помогает наглядно проанализировать текущие бизнес-процессы в информационной базе;
- описывает логическую взаимосвязь всех элементов в рамках предприятия;
- позволяет максимально задействовать типовые возможности выбранной конфигурации;
- позволяет принять решение о необходимости доработок системы, сформулировать постановку задачи на доработку;
- содержит реальный сквозной пример процессов предприятия по выбранным блокам;
- выполняется построение модели в выбранной типовой конфигурации (без доработок);
- моделирование бизнес-процессов производится в отдельной информационной базе "с нуля" на основании реальных данных, предоставленных заказчиком.
Что требуется от заказчика для выполнения этапа:
- выбрать интересующие блоки типовой конфигурации для построения модели;
- предоставить входные данные для выполнения первоначальных настроек и формирования сквозного примера;
- сформулировать основные бизнес-процессы, которые будут применяться на предприятии.
В результате моделирования заказчик получает:
- информационную базу, в которой выполнено моделирование основных бизнес-процессов;
- отчет по моделированию, содержащий описание возможностей типовой конфигурации по моделируемым блокам;
- реестр задач на доработку по результатам моделирования с оценкой плановой трудоемкости для перехода на следующий этап проекта.
ЭТАП 3. ФОРМИРОВАНИЕ ТЕХНИЧЕСКОГО ПРОЕКТА, РАЗРАБОТКА
Составляющие этапа:
- выполняется уточнение деталей;
- при необходимости формируется технический проект;
- описываются технические задания на доработку;
- выполняется разработка (программирование, настройка) в соответствии с реестром задач;
- разработка выполняется в тестовых базах;
- возможен вариант организации групповой разработки несколькими специалистами одновременно;
- изменения вносятся в информационную базу и сдаются заказчику на проверку.
ЭТАП 4. РАЗРАБОТКА СЦЕНАРИЯ ФОРМИРОВАНИЯ НАЧАЛЬНЫХ ДАННЫХ
Составляющие этапа:
- выполняется анализ существующей системы учета, данных;
- определяется набор данных, который планируется переносить в новую информационную базу (справочники, регистры сведений, документы и т.д.);
- разрабатывается сценарий переноса данных, методика переноса;
- при необходимости выполняется разработка обработок/правил конвертации для переноса данных;
- выполняется тестовый перенос данных в систему.
ЭТАП 5. ПЕРВОНАЧАЛЬНАЯ НАСТРОЙКА ПП 1С
Составляющие этапа:
- развертывание информационных баз на серверах заказчика;
- установка и настройка СУБД при клиент-серверном варианте работы 1С;
- активация лицензий;
- установка функциональных опций информационных баз и параметров учета;
- первоначальное заполнение нормативно-справочной информации, загрузка классификаторов;
- формирование организационной структуры предприятия в системе, создание пользователей;
- настройка профилей прав доступа пользователей.
ЭТАП 6. РАЗРАБОТКА ИНСТРУКЦИЙ И ОБУЧЕНИЕ ПОЛЬЗОВАТЕЛЕЙ
Возможные форматы обучения пользователей:
- прохождение курсов в центре сертифицированного обучения 1С по выбранной конфигурации/блоку учета;
- индивидуальное обучение в группах по блокам учета;
- обучение ключевых пользователей системы (для дальнейшей передачи знаний остальным сотрудникам);
- создание пользовательских инструкций и регламентов.
ЭТАП 7. ОПЫТНАЯ ЭКСПЛУАТАЦИЯ ПРОЕКТА
Составляющие этапа:
- подготовка к опытной эксплуатации системы;
- начало самостоятельной работы пользователей в тестовой базе;
- тестирование функционала системы;
- доработка и развитие функционала/исправление выявленных недочетов;
- проведение нагрузочного тестирования системы;
- подготовка к промышленной эксплуатации.
ЭТАП 8. ОКОНЧАТЕЛЬНЫЙ ПЕРЕНОС ДАННЫХ
Составляющие этапа:
- утверждение даты перехода на новую систему;
- подготовка данных для переноса;
- окончательный перенос данных к дате перехода;
- обработка данных после перехода.
ЭТАП 9. ПРОМЫШЛЕННАЯ ЭКСПЛУАТАЦИЯ ПРОЕКТА
Составляющие этапа:
КАК ОФОРМИТЬ ЗАЯВКУ
Внедрение системы "1С:Предприятие" требует присутствия специалистов на каждом этапе — от сбора информации до ввода в эксплуатацию.
Если вы уже понимаете, что в вашей компании требуется внедрение современной программы, которая будет учитывать все нюансы вашего бизнеса, обратитесь в ООО "Проектные решения".
Читайте также: