Построение
системы
- начальное обсуждение этапов построения системы;
- подготовка инфраструктуры для построения системы;
- разработка модификаций стандартной функциональности системы с учетом уникальных бизнес-процессов заказчика;
- внутренний юнит-тест модификаций;
- внутренний интеграционный тест;
- интеграционный тест пользователями заказчика;
- подготовка пользовательских процедур.
Внедрение
- начальное обсуждение этапов внедрения;
- инсталляция системы;
- настройка системы;
- перенос данных, заполнение справочников, импорт начальных остатков;
- обучение конечных пользователей функционалу решения.
Запуск
- запуск системы и ее поддержка на ежедневной регулярной основе;
- обзор конечных результатов проекта и определение его успешности.
Поддержка
- техническая поддержка системы силами специалистов интегратора.
Следует отметить,
что на каждом этапе ведется обучение
пользователей, особенно эффективно оно
проходит на этапе внедрения.
При разработке модификаций
в течение всего проекта использовалась
следующая архитектура.
Существовало три разных инсталляции
системы, каждая со своим приложением
и собственной БД:
- инсталляция для разработки — разработчики поставщика решения осуществляли программирование модификаций функционала, производили первичное тестирование и исправление найденных при тестировании ошибок:
- инсталляция для тестирования — после того как модификация проходила первичное тестирование и признавалась ведущим разработчиком соответствующей всем стандартам Microsoft, она переносилась на тестовое приложении. В этой инсталляции консультанты производили более глубокое тестирование функционала, в случае обнаружения ошибок модификация возвращалась на доработку программистам. После принятия консультантом решения о том, что модификация не содержит ошибок, привлекались пользователи заказчика, которые проводили еще тестирование, при этом решались две задачи: производилась дополнительная проверка модификации на соответствие потребностям пользователя, одновременно пользователи обучались операциям в системе, которые им предстояло в дальнейшем выполнять.
Все настройки и обучение пользователей консультантами в течение проекта также производились на тестовой инсталляции.
- рабочая инсталляция — в эту инсталляцию непосредственно перед запуском импортировались начальные остатки, сальдо по клиентам и поставщикам, справочники, производилась окончательная конфигурация системы. После окончательного интеграционного теста пользователями сюда попадал весь модифицированный функционал. Именно с этим приложением после запуска системы в промышленную эксплуатацию работают все пользователи.
Для регистрации
и планирования выполнения задач
на проекте, а также для оперативной
отчетности по статусам каждой конкретной
модификации или заявки пользователя
на доработку служила система
отслеживания и контроля запросов, разработанная в Columbus IT. Систему
применяли как специалисты интегратора,
так и представители ИТ-отдела заказчика.
Запуск системы
в головном офисе состоялся в
январе 2005 года, в течение января
— марта к системе были подключены
все региональные офисы компании.
Функциональные
характеристики внедренного решения
В рамках проекта
внедрения были автоматизированы следующие
участки заказчика.
1. Закупки
Операции по
регистрации закупок товара от поставщиков.
2.Управление
складом
Учет складских
запасов, перемещение запасов, оперативная отчетность
по складским запасам на всех складах
компании, ABC и XYZ анализ.
3. Продажи
Уникальные
бизнес-процессы заказчика по продажам
товаров клиентам были полностью
отражены в информационной системе.
4. Управление
цепочками поставок
Планирование
и отслеживание операций по транспортировке
товаров между собственными распределительными
центрами компании, учет транспортных
расходов в себестоимости продукции.
5. Расчеты с
поставщиками
Регистрация исходящих
платежей, сопоставление фактур с оплатами.
6. Расчеты с
клиентами
Регистрация входящих
платежей, расчет сальдо с учетом иерархической
структуры клиентов.
7. Финансовая
и управленческая отчетность
Использование
необходимых аналитических измерений
позволяет строить подробную
финансовую и управленческую отчетность.
8. Сводное планирование
В рамках проекта
была реализована комплексная система
расчета потребностей с учетом товарных
запасов, данных о закупках, сезонных
колебаний спроса. Также в этой
системе рассчитываются страховые
запасы по каждому из филиалов компании,
определяется оборачиваемость товаров
и синхронизируются спланированные заказы
с цепочками поставок.
Технические характеристики
внедренного решения
Система построена
в трехуровневой архитектуре
с использованием двух серверов приложений Axapta Object Server, объединенных
в кластер, одного сервера терминального
доступа, файлового сервера, на котором
находится приложение, и сервера баз данных
Microsoft SQL Server 2000.
Dependency
- Основной дескриптор: «Dependency».
- Эквивалентные понятия: «Dependency relationships»
- Использованные стандарты:
- UML – Unified Modeling Language
- Рабочие определения:
- In UML, a dependency relationship is a relationship in which one element, the client,
uses or depends on another element, the supplier. [UML – Unified Modeling Language]
- Dependency: A dependency is a directed relationship used when some element or a set of elements requires
(needs) other model elements for specification or implementation. It means that
complete semantics of the depending elements is either semantically
or structurally dependent on the the supplier element(s). [UML – Unified Modeling Language]
- Обновляемый блок:
- A dependency in the Unified Modeling Language exists between two defined elements if a change to the definition of one may result in
a change to the other. [Wikipedia - http://en.wikipedia.org/wiki/Dependency_(UML)]
- A dependency is a semantic relationship where a change to the influent or independent modeling element may affect the semantics of the dependent modeling element. [Wikipedia - http://en.wikipedia.org/wiki/Dependency_(UML)]
- A dependency identifies a set of model elements that requires other model elements for their specification or implementation. The complete semantics of the depending elements is either semantically
or structurally dependent upon the definition of the supplier element(s).
[Wikipedia - http://en.wikipedia.org/wiki/Dependency_(UML)]
- Тип связи: предмет - процесс
Artifact
- Основной дескриптор: «Artifact».
- Эквивалентные понятия: «model elements», « model».
- Использованные стандарты:
- RUP - Rational Unified Process
- UML – Unified Modeling Language
- Рабочие определения:
- Artifacts are either final or intermediate work products that are produced and used during a
project. Artifacts are used to capture and convey project information. [RUP - Rational Unified Process]
- An artifact is a classifier that represents some physical entity, a piece of information that is used or is produced by a software development process,
or by deployment and operation of a system. Artifact is a source of
a deployment to a node. A particular instance (or "copy") of
an artifact is deployed to a node instance.[ UML – Unified Modeling Language]
- Тип связи: процесс - предмет
Deployment target
- Основной дескриптор: «Deployment target».
- Использованные стандарты:
- UML – Unified Modeling Language
- Рабочие определения:
- Deployment
target is the location for a deployed artifact.[UML – Unified Modeling Language]
Artifacts are deployed to
deployment targets. Deployment target is the location for a deployed artifact.
UML 2.4 definition of deployment target
Instance specification was extended in UML 2.0 to allow instance of a node to be deployment target in a deployment relationship.
Property was also extended in UML 2.0 with the capability of being a deployment target in a deployment relationship. This enables modeling
the deployment to hierarchical nodes that have properties functioning
as internal parts.
Deployment target owns the
set of deployments that target it.
Deployment target has no specific notation by itself, see notations
for subclasses.
[http://www.uml-diagrams.org/composite-structure-diagrams.html#part]
- Тип связи: процесс - предмет
Процесс
- Основной дескриптор: «Процесс».
- Эквивалентные понятия: «Рабочий процесс»
- Использованные стандарты:
- ГОСТ Р ИСО 9000-2001 - Системы менеджмента качества. ОСНОВНЫЕ ПОЛОЖЕНИЯ И СЛОВАРЬ.
- RUP - Rational Unified Process
- Рабочие определения:
- Процесс – набор частично упорядоченных шагов для достижения цели. В ПО, цель – необходимость построения программного продукта или расширения существующего. В технологии, цель состоит в том, чтобы расширить или увеличить модель процесса; соответствует деловому прецеденту использования в деловой разработке. [RUP]
- Рабочий процесс – описание осмысленной последовательности задач и их взаимодействия между ролями, создающих видимый результат.[RUP]
- процесс (process): Совокупность взаимосвязанных или взаимодействующих видов деятельности, преобразующая входы в выходы. [ГОСТ Р ИСО 9000-2001]
- Тип связи: причина - следствие
Проект
- Основной дескриптор: «проект».
- Использованные стандарты:
- ГОСТ Р ИСО 9000-2001 - Системы менеджмента качества. ОСНОВНЫЕ ПОЛОЖЕНИЯ И СЛОВАРЬ.
- Cobit 4.1 Control Objectives for
Information and Related Technology (Задачи информационных и смежных технологий)
- Рабочие определения:
- Проект (project): Уникальный процесс, состоящий
из совокупности скоординированной и
управляемой деятельности с начальной
и конечной датами, предпринятый для достижения
цели, соответствующей конкретным требованиям,
включая ограничения сроков, стоимости
и ресурсов.[ ГОСТ Р ИСО 9000-2001]
- Проект (project): Структурированный комплекс видов деятельности, имеющий целью создать для
организации новую возможность (что необходимо,
но недостаточно для достижения требуемых результатов
бизнеса), основанный на согласованном
графике и бюджете.[ Cobit 4.1 Control Objectives for Information and Related Technology]
- Открытые источники:
- Проект - Уникальное предприятие, предполагающее координированное выполнение взаимосвязанных действий из различных функциональных областей, для достижения определенных целей в условиях временных и ресурсных ограничений. [http://www.prjman.ru/theory/19/]
Поставщик
- Основной дескриптор: «Поставщик».
- Эквивалентные понятия: «Производитель», «организация».
- Использованные стандарты:
- ГОСТ Р ИСО/МЭК 12207-99 - ПРОЦЕССЫ ЖИЗНЕННОГО ЦИКЛА ПРОГРАММНЫХ СРЕДСТВ
- ГОСТ Р ИСО/МЭК 15288 — 2005 - СИСТЕМНАЯ ИНЖЕНЕРИЯ
Процессы жизненного
цикла систем
- Рабочие определения:
- поставщик (supplier): Организация, которая заключает договор с заказчиком на поставку системы, программного продукта или программной услуги на условиях, оговоренных в договоре. [ГОСТ Р ИСО/МЭК 12207-99]
- организация (organization): Группа работников и необходимых средств с распределением ответственности, полномочий и взаимоотношений. [ГОСТ Р ИСО/МЭК 15288 — 2005]