Моделирование 1с что это

Обновлено: 04.07.2024

Прежде чем говорить об инструментах проектирования, хотелось бы остановиться на немаловажном вопросе: «для чего нужно проектирование информационных систем?». Достаточно популярным, особенно в среде 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С:Предприятие" требует присутствия специалистов на каждом этапе — от сбора информации до ввода в эксплуатацию.

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

Читайте также: