Лекция 6. Принятие решений о приобретении ИТ – продукта
Понятие тендера в отечественной практике выбора корпоративных информационных систем по сути не имеет строгой юридической базы, и большинство участников рынка понимают под ним прежде всего некую формализованную процедуру, цель которой — выбор программного продукта. Конечно, для того, чтобы термин “правильное решение” вообще имел смысл, должны быть поставлены адекватные цели (а их постановка, кстати, также может оказаться частью тендерной процедуры).
Тендер часто отождествляют с наличием нескольких альтернативных вариантов внедрения ПО, вовсе оставляя в стороне вопрос о методологии. Отсутствие жесткой процедуры, нацеленной на получение максимально объективного результата, вовсе не означает, что цель не будет достигнута. Именно это мы часто наблюдаем на практике.
Таким образом, понятие “тендер” можно определить как четко определенную последовательность организационных мероприятий, направленных на достижение максимальной объективности, необходимой для принятия правильного решения.
На вопрос о том, целесообразно ли проведение тендера в любой ситуации, отнюдь не всегда можно дать однозначно утвердительный ответ.
Набор факторов, которые говорят в пользу или же, наоборот, против проведения тендера, может определяться как внутренними традициями предприятия, так и необходимостью затрат определенных ресурсов на проведение тендера.
“Стоимость проведения тендера может составлять 20—30 тыс. долл., и основная часть указанной суммы — это рабочее время высшего руководства предприятия.
Если стоимость проекта превышает полмиллиона долларов, то тендер проводить однозначно стоит, поскольку слишком велика цена неправильных решений. Если же она оценивается величиной, меньшей 100 тыс. долл. выбирать систему следует стандартным путем”. Приведенные значения стоимости тендера кому-то могут показаться несколько завышенными, но, скорее всего, они относятся к крупным проектам, на которые в основном ориентирована компания.
Тендер может быть как открытый, так и закрытый.
Если вы хотите привлечь поставщиков к работе в одной для вас области, и еще неизвестно, какая из компаний, работающих в этом направлении, окажется достойным партнером, то целесообразно проведение открытого тендера, так как закрытый тендер предполагает реальный риск обокрасть самих себя.
Закрытый тендер проще. Он проводится в случаях, когда количество поставщиков ограничено или когда круг поставщиков достаточно хорошо знаком.
Зачем устраивать открытые тендеры, если пальцев одной руки хватит, чтобы перечислить лидеров в отдельно взятой рыночной нише? Рассылать техническое задание всем подряд глупо: зачем всем знать, какие в компании бизнес-процессы. Поскольку партнеры конкурируют между собой, есть возможность выбирать самые выгодные варианты.
Справедливость закрытого тендера обеспечивается строгим, как и при проведении открытого тендера, соблюдением правил. Процесс облегчается тем, что отпадает необходимость в жестком выполнении целого ряда требований, предусмотренных законодательством и обязательных для открытых тендеров. В частности, не нужно просматривать огромное количество предложений.
Для проведения тендера создается тендерный комитет, в задачу которого входит детальная оценка функциональности продуктов-финалистов. В комиссии однозначно должны быть представлены руководители всех ключевых подразделений заказчика. Более того, должно быть обеспечено одинаковое отношение ко всем участникам. “Абсолютно недопустима ситуация, при которой одну систему смотрит только главный бухгалтер, а вторую, например, начальник производства”.
Можно выделить три этапа проведения тендера
На первом этапе осуществляется подготовка и рассылка тендерных писем, форма которых может быть различной. “Первое письмо в размере одной-двух страниц должно рассылаться максимальному числу поставщиков и содержать набор вопросов, относящихся к основным критериям выбора системы, или могут содержать достаточно развернутые тезисы, в повествовательной форме характеризующие как состояние самого предприятия, так и набор стоящих перед ним задач.
Такая форма обычно практикуется в двух случаях: если организация тендера проводится целиком силами внешних консультантов, а также в нечасто встречающихся ситуациях, когда предметом выбора является вся информационная инфраструктура предприятия, а не только корпоративная информационная система
Конечно, в реальных условиях российского рынка этих компаний будет не более трех-четырех десятков, если даже постараться задействовать максимальное их число.
Как правило, определяется крайний срок подачи предложений (дату и время). В зависимости от того, о каком конкурсе идет речь, мы получаем эти предложения по электронной почте либо в закрытом конверте.
Специалисты анализируют полученную от партнеров информацию, затем матрица суммирует и формируется результат, на основе которого мы формулируем собственное предложение. Оно выносится на маркетинговую комиссию или на комитет по информатизации. Эти люди знакомятся с методологией выбора подрядной организации или поставщика ИТ. Если у них нет сомнений в том, что конкурс проведен в соответствии с заявленными правилами, то предложение подтверждается. Если комитет находит, что по каким-либо причинам будет разумнее “переиграть” конкурс, то процесс запускается повторно. Окончательный выбор производится на основе коллегиального решения.
Ко второму этапу тендера, по практически единодушному мнению специалистов, может допускаться лишь ограниченное количество продуктов и соответственно фирм-поставщиков, поскольку этот этап предполагает значительно более тесные и неформальные контакты заказчика с партнером, предлагающим предприятию систему управления.
На данном этапе должно остаться всего несколько компаний, а выбор начинает строиться на основе более сложного и творческого подхода, поскольку проводится посредством многокритериальной оценки, а не путем отсечения продуктов, явно не удовлетворяющих клиента по функциональности.
Определяется несколько фирм, с которыми вообще предстоит иметь дело в дальнейшем. При этом крайне желательно, чтобы присланные ответы были заверены подписью генерального директора компании-поставщика.
Последнее условие на практике оказывается далеко не второстепенным и, очевидно, диктуется необходимостью с самого начала придать последующей процедуре более весомый статус. Хорошо известно, что на основе положительных ответов впоследствии могут формулироваться конкретные пункты контрактных обязательств, а невыполнение каждого из них чревато для поставщика крайне негативными юридическими последствиями.
Возможно и изначальное сужение круга участников, которое зависит от квалификации и опыта заказчика или консультационной фирмы, привлеченной для проведения тендера.
“Пусть, например, мы хотим заменить сотню рабочих станций в одном из регионов. Это довольно значительные инвестиции. Мы рассылаем техническое задание четырем или пяти партнерам, работающим с нами по этому направлению, и объявляем им нашу систему оценки участников тендера. В ее основе лежит матрица с перечисленными в ней факторами, которые мы считаем важными в данном случае. В их числе могут быть стоимость, надежность и скорость поставки, предшествующие отношения с нами и т.д. Затем мы получаем и оцениваем предложения наших партнеров”.
На этой стадии заказчик куда сильнее оказывается вовлечен в работу по выбору системы, которая к тому же становится и более интеллектуальной. Как следствие, возрастает роль тендерной комиссии.
Поскольку на данном этапе речь идет о вещах более тонких, чем просто наличие или отсутствие той или иной функциональности, почти всегда стараются найти компромиссные решения. Например, у одной компании может быть меньше опыта внедрения в нужной отрасли, но, скажем, лучше поддержка. Все это диктует необходимость аккуратного подхода к оценке оптимальности выбираемого решения. “Мы стараемся, чтобы на этапе очной работы с поставщиками вся процедура была максимально открытой и каждый из представителей тендерной комиссии в любой момент мог высказать свое мнение. Если с самого начала будут какие-то недоговоренности, то и без того сложный процесс внедрения усложнится в несколько раз”.
На третьем этапе остаются, как правило, всего две компании. Принципиально этот этап не отличается от предыдущего, если не считать того, что оценка решение в этом случае предельно тщательно, а отношения поставщик - клиент часто еще более неформальны. На этом этапе попытка заказчика максимально “прогнуть” цены в свою пользу — вполне обычная форма взаимных контактов.
Один из популярных приемов, практика применения которого напрямую связана с тонкостями оценки систем при детальном знакомстве с ними, а также в определенной степени с не слишком большой щепетильностью поставщика при ответах на поставленные вопросы, — выполнение им тестовых примеров.
“Для того, чтобы понять, насколько правильно разработчик и поставщик отвечают на те вопросы, которые заданы в тендерном письме, при проведении тендеров используется практика тестовых примеров. Их необходимо составить так, чтобы результат выполнения примера четко отвечал на поставленный вопрос и вместе с тем выполнение примера не потребовало от разработчика или поставщика больших усилий”. Подчеркнем, что цель подобных примеров — все-таки стремление проникнуть в детали функционала системы, которые могут быть истолкованы либо неполно, либо вообще неправильно. К числу таких свойств специалисты относят, например, тезис о поддержке многовалютности. Вообще говоря, разглядеть в предлагаемом решении потенциально спорные моменты да еще грамотно составить сам тестовый пример достаточно сложно, и выполнение подобных работ требует от организатора тендера, будь то сам заказчик или консультант, и опыта, и квалификации.
Имеет смысл ставить данный вопрос только тогда, когда речь идет о первом внедрении системы в отрасли. Если же на производстве подобного типа программное решение уже где-то используется, разумно выяснять нюансы функциональных свойств систем на основе реально работающего прототипа.
Использование консультанта при проведении тендера
Еще один ключевой вопрос организации процедуры проведения тендера связан с тем, насколько необходимо присутствие в ней консультационной компании. А если без консультанта все-таки не обойтись, его роль и степень участия в тендере должны быть четко обоснованы.
Часто подразумевается, что, если консультант берет на себя труд и ответственность по выбору системы для заказчика, его роль только этим не ограничивается. На этапе, предшествующем тендеру, он принимает участие в формулировке требований к программному обеспечению, активно влияя на мнение заказчика, а впоследствии займется внедрением системы вплоть до полного достижения целей, поставленных на первоначальном этапе, и будет к тому же отвечать за их достижение. Более того, в принципе не лишен практического смысла сценарий, когда консультант берет на себя всю работу по выбору и внедрению ПО, максимально освобождая от этих забот клиента и неся таким образом исключительную ответственность за достижение конечного результата. К тому же в данном случае вполне можно вести речь о предоставлении финансовых гарантий — а это, по сути, идеальная форма ответственности сторонней фирмы перед заказчиком.
И пусть такой вариант на практике пока не встречается, некая промежуточная ситуация все же реализуема. Нередки случаи, когда консультант полностью проводит селекцию претендентов на первом, формальном этапе тендера, а заказчик подключается к работе впоследствии, когда требуется более детальный подход. Такая ситуация имела место, например, на Нижнетагильском металлургическом комбинате, одном из первых крупных клиентов SAP в России.
Перспективы участия консультанта в последующих стадиях проекта часто влияют и на тактику проведения им тендерной процедуры. Причем создается впечатление, что за этим кроется ряд неоднозначных моментов. Дело в том, что в случае привлечения консультационной компании к внедрению выбранной системы (а это, как мы выяснили, в принципе позитивная ситуация) отдельные этапы работы могут выполняться фактически авансом. В частности, это относится к обследованию бизнес-процессов на предприятии, которое может проводиться с той или иной степенью подробности. “Интервал от начала работы до момента, когда окончательный выбор сделан, может объективно занимать до четырех месяцев. Если это приличное по размерам предприятие, то только его обследование, как правило, длится не меньше трех месяцев. Тендерное письмо при этом может содержать до полусотни страниц, в которых мы пытаемся не только сформулировать основные требования к системе, но и описать структуру компании и ее особенности”.
Консультант просто переносит часть собственной работы по обследованию предприятия (обычно выполняемой на стадии внедрения) на этап проведения тендера. Возможность осуществления подобного маневра — фактор безусловно благоприятный: на стадии выбора иметь более детальную картину бизнеса компании крайне полезно.
Как учитывать технологии
Один из потенциально спорных моментов, касающихся постановки задач при выборе, состоит в том, целесообразно ли рассматривать технологические особенности решений. С одной стороны, известно, что выбор системы должен делаться бизнесом и для нужд бизнеса, а, следовательно, функционал программного обеспечения необходимо рассматривать исключительно с этой точки зрения.
Понятно, что наиболее ключевые из них напрямую связаны с качеством сервиса, который будет в конечном итоге отражать адекватность решения бизнес-задач. Уже на первом этапе выбора, на котором решаются вопросы принципиальной годности систем, такие технологические аспекты, как используемый сервер баз данных или, например, наличие в системах поддержки CASE-технологии, обязательно должны приниматься во внимание. Кроме того, технологические акценты при выборе должны по идее играть тем большую роль, чем мощнее к моменту выбора комплексной системы управления оказывается накопленная инфраструктура автоматизации на предприятии и чем более акцентировано стремление организации интегрироваться в отраслевые проекты электронного бизнеса.
Нацеленность тендерной процедуры на объективность и учет максимального числа возможных факторов вряд ли позволяет вовсе обойти вниманием технические вопросы. При традиционном порядке выбора системы — и множество описанных нами проектов прямо подтверждают данный факт — чисто технические вопросы очень редко ставятся в ряд критериев ранжирования корпоративных систем на предмет их оптимальности для автоматизации бизнес-процессов (хотя, надо признаться, бывают и исключения). Вопрос о том, должны ли технологические вопросы входить в список критериев, в соответствии с которыми выбирается корпоративная система, в свою очередь, связан с проблемой привлечения к тендерной процедуре технических специалистов.
Таблица анализа информационной системы
№ п/п
Критерии
Оценка
Текстовое пояснение
Диапазон оценки:
Если оценка не применима, следует указывать абсолютную величину или ограничиться пояснением
0
Функция (возможность) отсутствует
1
Предполагается в следующей версии
2
Требует незначительных усилий по доработке
4
Реализована и работает в российских условиях (нерусифицирована)
5
Реализована и работает в российских условиях (русифицирована)
1. Фирма - поставщик
1.1
Основные критерии
1.1.1
Количество лет в бизнесе
1.1.2
Количество лет в России
1.1.3
Представительство в России
1.1.4
Количество партнеров в России
1.1.5
Мультинациональность (представительства во многих странах)
Итого по основным критериям
1.2
Внутренняя организация фирмы
1.2.1
Подразделение разработки и исследования
1.2.2
Подразделение продаж
1.2.3
Подразделение маркетинговых исследований
1.2.4
Каналы распространения
1.2.5
Подразделение внедрения продуктов
1.2.6
Подразделение сопровождения продуктов
1.2.7
Подразделение консультаций
1.2.8
Подразделение обучения
Итого по внутренней организации
1.3
Организация бизнеса в России
1.3.1
Подразделение разработки и исследования
1.3.2
Подразделение продаж
1.3.3
Подразделение маркетинговых исследований
1.3.4
Каналы распространения
1.3.5
Подразделение внедрения продуктов
1.3.6
Подразделение сопровождения продуктов
1.3.7
Подразделение консультаций
1.3.8
Подразделение обучения
1.3.9
Количество специалистов, обеспечивающих сопровождение и консультации
Итого по внутренней организации
Итого по фирме-поставщику
2. Система
2.1
Общие критерии
2.1.1
Специализация для (указать отрасли промышленности)
2.1.2
Множественность балансовых единиц
2.1.3
Управление комплексной структурой предприятия
2.1.4
Интегрированность оперативного, управленческого и финансового учета
2.1.5
Гибкость при изменяющихся бизнес условиях
2.1.6
Полиотчетность, многовалютность
2.1.7
Экспорт и импорт данных и отчетов
2.1.8
Возможность создания прототипов форм, отчетов
2.1.9
Разработка версий под российский рынок
Итого по общим критериям
2.2
Характеристики реализации
2.2.1
Максимальное количество одновременно работающих пользователей
2.2.2
Требования к сети и аппаратной платформе
2.2.3
Максимальное количество аналитических признаков на единицу учета
2.2.4
Максимальный диапазон хранимых сумм
2.2.5
Максимальный размер стандартного текстового поля
2.2.6
Максимальный размер мемориального (ссылочного) текстового поля
2.2.7
Технология клиент-сервер
2.2.8
Технология Intranet/Internet
2.2.9
Многоплатформенность (UNIX, AS/400, S 390, Windows NT)
2.2.10
NetWare
2.2.11
Использование промышленных СУБД (Oracle, Informix, Sybase и т.д.)
2.2.12
Масштабируемость (легкость расширения и сужения системы)
2.2.13
Эффективность работы при одновременном обслуживании более 100 пользователей
2.2.14
Эффективность работы при интенсивности прироста информации: 1000 документов и 100000 аналитических операций (проводок) в день
2.2.15
Наличие метаязыковых средств описания и настройки данных и процедур системы
2.2.16
Многоплатформенность клиентской части (Windows, DOS)
2.2.17
Наличие средств OLAP
2.2.18
Отсутствие перерывов в работе для обслуживания системы (архивирование, проверка целостности)
Итого по характеристикам реализации
2.3
Функциональные требования
2.3.1
Управление финансами (корпорация, подразделения)
2.3.2
Управление основными средствами
2.3.3
Финансовое планирование и бюджетирование
2.3.4
Управление инвестициями
2.3.5
Управление закупками
2.3.6
Управление запасами (товародвижение)
2.3.7
Управление продажами
2.3.8
Маркетинг (поставщики, заказчики)
2.3.9
Управление затратами
2.3.10
Управление заработной платой
2.3.11
Управление персоналом
2.3.12
Управление проектами
2.3.13
Управление производством: дискретное и непрерывное
2.3.14
Управление цепочками поставок (поставщик-предприятие-заказчик)
2.3.15
Управление транспортом и перевозками
2.3.16
Планирование, в том числе с учетом ограничений
2.3.17
Управление оказанием услуг клиентам (заказы: интеграция с запасами, производством, НПЗ, транспортировкой)
2.3.18
Управление качеством
2.3.19
Наличие средств построения модели предприятия
Итого по функциональности
3. Требования к базам данных
3.1
Степень внешней интеграции
3.1.1
Интеграция с другими приложениями для конечного пользователя
3.1.2
Интеграция с E-mail
3.1.3
Интеграция с Internet/Intranet
3.1.4
Интеграция с системой iMAN (указать уровень интеграции)
3.1.5
Интеграция с системами документооборота (Documentum, DOCS Open и т.д.)
Итого по степени внешней интеграции
3.2
Степень внутренней интеграции
3.2.1
Формирование информации верхних уровней непосредственно из информации нижних уровней любого модуля
3.2.2
Детализация информации до источников любого нижнего уровня любого модуля любого филиала (drill down)
3.2.3
Настраиваемое изменение статуса подразделений (от статуса центра учета до балансовой единицы и обратно)
3.2.4
Настраиваемая функциональная увязка аналитических признаков нижних уровней с аналитическими показателями верхних уровней
3.2.5
Отсутствие необходимости повторного ввода данных
Итого по степени внутренней интеграции
3.3
Управление данными
3.3.1
Разграничение полномочий пользователей по функциям
3.3.2
Разграничение доступа к данным
3.3.3
Разграничение по группам пользователей
3.3.4
Кодирование данных
3.3.5
Автоматическое обеспечение целостности данных
3.3.6
Отслеживание лимита по объему данных
3.3.7
Возможности автоматического архивирования данных
3.3.8
Резервное копирование данных
3.3.9
Восстановление данных
3.3.10
Возможности репликации данных
3.3.11
Возможности распределения приложений и баз данных
3.3.12
Оптимизация хранения данных
3.3.13
Наблюдение за использованием приложений
3.3.14
Наблюдение за использованием данных
Итого по управлению данными
Итого по базам данных
3.4
Простота в использовании
3.4.1
Возможность изменения интерфейса для каждого пользователя
3.4.2
Стандартизация клавиш и управляющих графических элементов по всем модулям
3.4.3
Стандартизация стиля экранных форм
3.4.4
Возможность массового ввода без использования «мыши»
3.4.5
Возможности формирования собственных меню, формы, отчета
3.4.6
Быстрота заполнения полей справочной информацией (эффективность заполнения lookup полей)
Итого по простоте в использовании
3.5
Простота внедрения
3.5.1
Наличие встроенных средств построения бизнес модели предприятия и автоматического формирования структур данных и экранных форм
3.5.2
Наличие фирменной методологии внедрения
3.5.3
Наличие библиотеки настроек (для российского бухгалтерского учета: стандартная отчетность, корреспонденция счетов, сторнирование, взаимозачеты и пр.)
3.5.4
Возможность быстрой перенастройки системы во время внедрения
4. Поддержка и сопровождение
4.1
Техническая поддержка
4.1.1
Простота связи с фирмой
4.1.2
Оперативность ответной реакции
4.1.3
Аккуратность ответа
4.1.4
Консультационные услуги
4.1.5
Локальная поддержка
4.1.6
Справочные услуги (по телефону)
4.1.7
Справочные услуги (online)
4.1.8
Информация о новостях
4.1.9
Гарантия
4.1.10
Сопровождение продукта
4.1.11
Обеспечение новыми версиями
Итого по технической поддержке
4.2
Обучение
4.2.1
Обучение на рабочем месте
4.2.2
Обучение у поставщика средств
4.2.3
Самообучение
4.2.4
Обучение у третьих компаний
4.2.5
Руководство по инсталляции
4.2.6
Руководство пользователя
4.2.7
Сообщения об ошибках
4.2.8
Техническое руководство
Итого по обучению
Итого по поддержке и сопровождению
5. Требования со стороны бизнес-процессов
5.1
Управление финансами
5.1.1
Составление финансового плана на основании внесенных запланированных данных по доходам и расходам в аналитике по подразделениям
5.1.2
Планирование денежных потоков
5.1.3
Наличие системы банк-клиент. Возможность использования внешней системы банк-клиент
5.1.4
Определение временных рамок наличия свободных денежных средств / потребности в денежных средствах, как в рублевых, так и валютных
5.1.5
Возможности нормирования расходов в соответствии с составом затрат, сметой проектов и т.п. в аналитике по подразделениям
5.1.6
Наличие системы утверждения предварительно сформированных платежей
5.1.7
Возможность разбиения поставок товара и оплату на частичной основе
5.1.8
Разноска платежей (в т.ч. сформированных ранее) по мере подтверждения оплаты
5.1.9
Опция возврата платежа (как неверно перечисленного и т.п.)
5.1.10
Опция информирования всех заинтересованных лиц о внесенных изменениях в закрытых периодах
5.1.11
Формирование стандартных статистических отчетов по финансовой части
Итого по финансовому отделу
5.2
Бюджетирование и планирование
5.2.1
Возможность ввода плановых показателей и анализа их выполнения
5.2.2
Возможность корректировки плановых показателей в течение отчетного периода
5.2.3
Возможность формирования планового задания в отдельности по каждому подразделению и анализ выполнения
5.2.4
Бюджетирование расходов по центрам затрат, проектам и подразделениям / центрам ответственности
5.2.5
Автоматическое формирование Российского и Западного балансов и приложений к балансу
5.2.6
Стандартный анализ финансовых показателей на основании данных балансового отчета
5.2.7
Формирование необходимых расчетных форм на основании данных баланса и приложений к нему
5.2.8
Возможность организации интерфейса с внешними программными средствами с целью проведения анализа и дополнительных расчетов (специальные программы, Excel, Access, Power Builder)
5.2.9
Возможность ведения учета на удаленных местах (возможность импорта с носителей, модемная связь, удаленный автономный терминал и т.п.)
5.2.10
Возможность планирования платежей будущих периодов, в т.ч. на основании статистических данных прошлых периодов
5.2.11
Возможность оперативного доступа к данным за предыдущие периоды (какова глубина доступа: 1 год, 2 года …)
5.2.12
Консолидация данных (плановых, бюджетных, фактических) на уровне центров затрат, проектам и подразделениям / центрам ответственности
5.2.13
Контроль проектов (открытие, приостановление, закрытие, перераспределение) – связано с работой секций, важна индикация текущего состояния
5.2.14
Возможность настройки выходных форм аналитических отчетов, возможность изменения стандартных
5.2.15
Однократный ввод валютных курсов и возможность использования таблицы валютных курсов внешними средствами обработки данных
Итого по бюджетированию и планированию
5.3
Бухгалтерия
5.3.1
Средства детального анализа баланса по подразделениям
5.3.2
Наличие буфера накопления проводок для ввода их в Главную Книгу
5.3.3
Возможность получать отчеты и делать корректировки для проводок, находящихся в буфере (если он есть)
5.4
Учет расчетов с рабочими и служащими
5.4.1
Доступ (интеграция) к данным отдела кадров, приказам по персоналу: зачисление, увольнение, перевод, изменение в штатном расписании
5.4.2
Интеграция с модулем «счета к оплате» – для регистрации задолженностей по налогам и удержаниям
5.4.3
Ввод и авторизация табелей учета рабочего времени в комплексах/секциях. Проверка табелей и их авторизация в режиме on-line
5.4.4
Запросы по расчетам (начисления, удержания, авансы, расчет пенсии, детские компенсации) с персоналом в режиме on-line
5.4.5
Вся информация по начислениям в фонды социального и медицинского страхования доступна из модуля учета расчетов по зарплате
5.4.6
Возможность ввода графика учета рабочего времени – ФИО, дата, время начала и время окончания
5.4.7
Возможность регистрации нарядов на сдельную работу, расчет зарплаты сдельщиков
5.4.8
Возможность регистрации нарядов на сдельную работу в местах их возникновения, расчет зарплаты сдельщиков
5.4.9
Ведение картотеки депонированной зарплаты
5.4.10
Возможность организации расчета заработной платы с учетом положений УМПО по оплате
5.4.11
Формирование платежных ведомостей на выплату зарплаты
через кассу
5.4.12
Перечисление зарплаты для выплаты через Сбербанк (пластиковые карты)
5.4.13
Организация перечисления удержаний из зарплаты за коммунальные услуги, Госстрах, кредит, ссуды, алименты, питание в столовых УМПО, покупку товаров УМПО в счет зарплаты и др.
5.4.14
Формирование финансового свода по подразделениям, заводам
5.4.15
Интеграция с модулем «Главная книга»
5.4.16
Возможность ведения персонифицированного учета согласно требований Пенсионного фонда
5.4.17
Возможность ведения картотеки совокупного годового дохода по работающим согласно требований ГНИ
Итого по учету с рабочими и служащими
5.5
Учет банковских и кассовых операций
5.5.1
Ввод графика платежей на месяц вперед, планирование платежей
5.5.2
Возможности контроля и планирование остатка на счетах
5.5.3
Средства генерации платежных документов: платежных поручений, расходных кассовых документов, заявлений на перевод (в валюте)
5.5.4
Регистрация поступающих платежных документов (платежных поручений)
5.5.5
Генерация отчета о движении денежных средств по форме № 4
5.5.6
Расчеты с подотчетными лицами (регистрация авансовых отчетов). Контроль срока задолженности подотчетного лица
5.5.7
Ведение паспортов сделки, регистрация таможенных деклараций
5.5.8
Расчеты (регистрация) в кассе приходных и расходных ордеров
5.5.9
Возможность формирования платежных поручений, счетов-фактур по расчетам с потребителями на базе данных приказов на отгрузку продукции отделом сбыта
5.5.10
Возможность формирования взаимозачетов
5.5.11
Возможность формирования книги покупок и продаж согласно требований ГНИ
Итого по учету банковских и кассовых операций
5.6
Учет основных средств, МБП, материалов
5.6.1
Возможность регистрации всей необходимой информации по основному средству в момент приобретения – инв. номер, коды, суммы как в соответствии с российским учетным законодательством, так и в соответствии с GAAP
5.6.2
Наличие функций обработки запросов по основным средствам в режиме on-line
5.6.3
Возможность печати инвентарных ярлыков с цифровым и штрих кодовым номерами (для нужд инвентаризации)
5.6.4
Движение, оценка и начисление амортизации – в соответствии с российским законодательством и GAAP
5.6.5
Возможность регистрации информации о движении основных средств и произведенных ремонтах и модернизациях
5.6.6
Возможность выверки между учетными данными (первоначальная стоимость, накопленный износ) по российским данным и по GAAP
5.6.7
Возможность переоценки основных средств в соответствии с российским законодательством
5.6.8
Использование повышающих -понижающих коэффициентов при расчете амортизации
5.6.9
Ввод накопленной амортизации для старых основных средств
5.6.10
Возможность текстового расчета амортизации
5.6.11
Возможность привязки основных средств к разным категориям, для которых определены разные способы расчета амортизации
5.6.12
Возможность приостанавливать амортизацию на указанный период
5.6.13
Расчет амортизации в режиме пакетного ввода
5.6.14
Перерасчет амортизации в закрытых периодах
5.6.15
Возможность перевода основных средств из одной категории в другую (например, в МБП)
5.6.16
Привязка материально-ответственных лиц.
Интеграция с модулем Персонала
5.6.17
Привязка к центрам затрат. Интеграция с модулем управления затратами
5.6.18
Учет драгметаллов
а) в материалах
б) в основных средствах
Итого по учету основных средств
5.7
Учет и планирование производства
5.7.1
Возможность регистрации и авторизации заказов на производство, возможность автоматического создания номенклатурной единицы для заказа по спецификации. Каждый заказ клиента отличается как видами готовой продукции предприятия, так и видами и марками материалов, из которых она должна быть изготовлена, дополнительными технологическими особенностями
5.7.2
Возможность изменения существующего заказа в режиме он-лайн
5.7.3
Обеспечение связи между заказом и производственным процессом. По каждому заказу клиента в системе должна быть возможность определения маршрута обработки (участки, станки/механизмы, время), а также необходимых материалов (закупаемых или производимых). Доступность информации по запасам и незавершенному производству для удовлетворения заказа.
5.7.4
Возможность оперативной замены номенклатурной единицы на альтернативную
5.7.5
Наличие шаблонных форм ввода заказа
5.7.6
Возможность работы в смешанных системах планирования
5.7.7
Учет побочных и попутных продуктов. Управление формулами изделий
5.7.8
Возможность управления смешанными процессами. Система должна поддерживать учет производительности и использования ресурсов (в т.ч. временных) в разрезе станков/механизмов с группировкой по участкам производства (с возможностью учета как нормативных, так и фактических величин)
5.7.9
Возможность привязки материалов к станкам и участкам (многие ко многим), с указанием вида операции, выполняемой на данном станке с материалом. Возможность определения норм расхода материалов, нормативного времени обработки материалов в разрезе станков и операций
5.7.10
В системе должны быть функции для определения норм расхода материалов, нормативного времени обработки материалов в разрезе станков/механизмов и операций
5.7.11
Система должна поддерживать учет рабочего времени как в машино-часах, так и в человеко-часах
5.7.12
В системе должна быть возможность учета по каждому материалу (как нормативные, так и фактические данные) с использованием различных единиц (кг., тонны, шт.) с возможностью пересчета из одной единицы в другую
5.7.13
Планирование с учетом «наличное для обязательств» и «возможное для обязательств»
5.7.14
Возможность учета следующей технологической информации по клиентским заказам по каждому участку:
- заказ
- участок
- оборудование
- материалы
- отходы
- время начала выполнения
- время окончания выполнения
- дополнительные технологические сведения
- мастер, отвечающий за выполнение заказа
- рабочий, отвечающий за выполнение операций по заказу
5.7.15
В системе должна быть возможность учета обработки заказа на одном станке / механизме несколькими сменами рабочих (по каждой смене и заказу должны учитываться затраты рабочего и машинного времени, использованные материалы, объем незавершенного производства, объем выпуска продукции
5.7.16
Связь заказа с транспортировкой, упаковкой, видом крепления
5.7.17
Ведение книги выполнения заказов
5.7.18
При подготовке ежемесячного плана производства система должна как обеспечивать информацию по планируемым заказам, так и по запасам на складе готовой продукции и незавершенному производству
5.7.19
Система должна поддерживать подготовку, корректировку и контроль выполнения ежемесячных планов производства в разрезе клиентских заказов
5.7.20
В системе должны быть обеспечены возможности планирования загрузки оборудования на основе информации по обрабатываемым заказам и заказам, ожидающим обработки. При этом система должна обеспечивать возможность расстановки приоритетов заказов с учетом правила, что исполнение заказа на станке не может быть прервано для исполнения другого заказа
5.7.21
Система должна поддерживать процесс маршрутизации заказа с использованием классификаторов оборудования, операций, материалов и сырья, промежуточных продуктов. При этом плановик должен иметь возможность оценки различных маршрутов производства (по ресурсам) и эффективности
5.7.22
Система должна автоматически рассчитывать затраты на изготовление заказа на основе сформированного маршрута (с учетом норм брака, времени на переналадку оборудования, дополнительного времени рабочих и т.д.)
5.7.23
В системе должен быть автоматизирован процесс получения маршрутных и технологических карт (в разрезе станков, заказов, материалов)
5.7.24
Система должна контролировать отклонения нормативных затрат на выполнение заказа, которые отличаются от плановых калькуляций по предварительному заказу на определенную величину (к примеру, 1%)
5.7.25
В системе должны учитываться затраты машинного и рабочего времени (в том числе времени на переналадку оборудования), материалов на выполнение заказа – позаказно, посменно, в разрезе участков и оборудования с указанием рабочих, выполнивших заказ
5.7.26
В системе должен учитываться выпуск готовой продукции, незавершенное производство – позаказно, посменно, в разрезе участков и оборудования с указанием рабочих, выполнивших заказ
5.7.27
Информация о фактических затратах (26,27) должна заводится в систему в местах возникновения и быть доступной другим
5.7.28
В системе должны быть средства для формирования оперативной информации по производству:
- выполняемые в текущий момент заказы (срок выполнения, % выполнения) по оборудованию и участкам
- фактические и планируемые переменные затраты на производство по заказам (сравнение фактических затрат с нормативными затратами и затратами, определенными при подготовке предварительного заказа)
- фактический и планируемый выпуск по заказам в разрезе участков, оборудования, рабочих, смен
- фактические временные затраты / плановые временные затраты на выпуск продукции в разрезе заказов, участков, оборудования, рабочих
- загрузка оборудования (заказы, обрабатываемые в настоящий момент, заказы, ожидающие выполнения)
5.7.29
В системе должны быть средства для формирования ежемесячных заявок на закупку на основании плана производства
5.7.30
В системе должны быть средства для формирования ежемесячных заявок на закупку на основании плана производства с учетом истечения срока годности комплектующих и агрегатов, имеющих ограниченный срок годности (подшипники, резина и т.д.) , а также допустимые замены при использовании остатков
5.7.31
Система должна поддерживать выполнения функции контроля годового и квартальных планов производства (на основе сравнения агрегированных плановых показателей по выпуску различных видов продукции и фактических данных)
5.7.32
Расчет сводных норм на изделие
5.7.33
Расчет спецификации материалов по цеху в разрезе изделий
5.7.34
Учет и планирование отходов по материалам
5.7.35
Ведение ведомости оснащения
5.7.36
Система учета и планирования оснащения
5.7.37
Наличие ИПС (информационно-поисковая система инструмента)
5.7.38
Создание сопроводительной карты при запуске деталей, сборочных единиц и ввод отметок о перемещении по технологическому маршруту в интерактивном режиме.Отметка о перемещении должна содержать дату, время проведения операции, подтверждение сдатчика и получателя.
5.7.39
Сигнализация о нарушениях в учетных документах, таких как появление минусовых остатков
5.7.40
Возможность ведения учета как партиям, так и в накопительном режиме
5.7.41
Возможность перемещения деталей, сборочных единиц с отклонением от технологического маршрута (со скачком по маршруту, обратно и т.д.)
5.7.42
Наличие учетной операции разделения : одна заготовка – несколько деталей
5.7.43
Возможность ‘разметки’ рассчитанных потребностей по источникам возникновения: исходный заказ, дата изготовления заказа, цех-получатель
5.7.44
Учет активности спецификации и маршрута.
5.7.45
Возможность задания приоритетов и ограничений при гашении потребностей остатками
5.7.46
Наличие алгоритма обработки отрицательных остатков
5.7.47
Возможность трассировки расчета потребностей до товарных заказов
5.7.48
Возможность оперативного перепланирования по изменениям.
5.7.49
Возможность задания альтернативных спецификаций на изделия и узлы и альтернативных маршрутов изготовления
5.7.50
Возможность учета проведения изменений по всем нормативным базам данных на определенное количество комплектов изделия, на определенный интервал времени, с использованием задела
5.7.51
Возможность проведения изменений по всей нормативной базе данных на прогнозируемые изменения
5.7.52
Фиксация нормативных данных по изделиям на дату отгрузки, ее архивация и хранение в течение 20 лет
5.7.53
Возможность разграниченного доступа к нормативной информации по изделиям: планируемым и не планируемым
5.7.54
Ведение журнала регистраций изменений по всем нормативным и оперативным данным с указанием автора изменений и основания для его проведения в течении всего периода существования изделий
Итого по учету производства
5.8
Сводная отчетность и налогообложение
5.8.1
Возможность регистрации балансов дочерних компаний в отдельные базы данных (раздельные «Главные Книги»). Консолидация балансов.
5.8.2
Возможность генерации финальных финансовых отчетов для публикации и предоставления в ГНИ на основе проводок
5.8.3
Возможность переоценки счетов расчетов в иностранных валютах (централизованно)
Итого по сводной отчетности и налогообложению
5.9
Инвентаризация, контроль и сохранность имущества
5.9.1
Ведение книги приказов на проведение инвентаризации, генерация (печать) приказов
Итого по инвентаризации, контролю и сохранности имущества
5.10
Ценообразование
5.10.1
Возможность изменения торговых надбавок на товары с их автоматическим пересчетом
5.10.2
Автоматический пересчет товарных запасов, учитываемых в валюте (USD, DM), в рубли
5.10.3
Автоматический расчет отпускных / розничных цен от контрактной с использованием таких параметров как торговая надбавка, НДС, таможенная очистка
5.10.4
Ведение истории закупочных цен (необходимы данные по первоначальным контрактным ценам)
5.10.5
Доступ к историческим данным по ценам, в т.ч. с возможностью сортировки условий выборки
5.10.6
Планирование и установка скидок на определенный период и на определенные группы изделий
5.10.7
Расчет статистических ценовых показателей
Итого по ценообразованию
5.11
Управление товародвижением
5.11.1
Ведение справочника номенклатуры
5.11.2
Поступление и приходование на склад
5.11.3
Формирование приходных накладных
5.11.4
Анализ данных о поставщиках
5.11.5
Создание заказов на поставку и контроль за их выполнением
5.11.6
Ведение истории документа (заказа, договора, контракта)
5.11.7
Работа со многими, в т.ч. удаленными складами
5.11.8
Аналитические отчеты
5.11.9
Формирование инвентаризационной описи («плюс» дополнительная настройка выводимых полей, таких как, первоначальные контрактные цены, текущие цены, группы, партии, артикулы и т.п.)
5.11.10
Формирование необходимых отчетов по товарным запасам и товародвижению («плюс» дополнительная настройка выводимых полей, таких как, первоначальные контрактные цены, текущие розничные цены, товарные группы, артикулы и т.п.)
5.11.11
Опция внутреннего перемещения товара, а также перемещения товара внутри корпорации / холдинга
5.11.12
Списание товаров
5.11.13
Учет в количественном выражении, учет в суммовом выражении и в различных валютах
5.11.14
Анализ товарооборота:
- по подразделениям, в т.ч. внутри корпорации / холдинга
- по товарным группам и подгруппам
- за период и нарастающим итогом
- планирование на будущие периоды на основании результатов продаж
5.11.15
Анализ товарных запасов:
- по подразделениям, внутри корпорации / холдинга
- по товарным группам и подгруппам
- по суммам и дням
- товары с длительной реализацией
5.11.16
Аналитика по поступлениям:
- по подразделениям, в т.ч. внутри корпорации / холдинга
- суммовой и по потерям в товарообороте
- графическое представление
- расчет оплаты поставщикам и таможне исходя из фактической выручки за день
5.11.17
Учет запасов по поставщику в аналитике по секциям, складам, валютам
5.11.18
Стандартная опция сортировки наименований товара, как по артикулу, так и по коду товара
5.11.19
Формирование центров прибыли по товарным группам
5.11.20
Установление кодировочных связей для совмещения одного плана товарных групп с другими внешними
5.11.21
Глубина разбивки по товарным группам, подгруппам и т.д. (сколько уровней)
5.11.22
Планирование закупок по группам товаров, по филиалам, по ценам закупки и реализации и т.п.
5.12
Маркетинг / Поставщики
5.12.1
Наличие модуля маркетинга для проведения маркетинговых исследований (с учетом торговых организаций)
5.12.2
Ведение базы данных поставщиков
5.12.3
Выход в интернет, e-mail и т.д.
5.12.4
Возможность контроля поставщиков на дублирование (по названию, по коду в налоговой инспекции и т.п.)
5.12.5
Возможность группировки поставщиков / покупателей, имеющих один код в налоговой инспекции, одно название и т.п.
5.12.6
Занесение данных по условиям оплаты отдельно для каждого из поставщиков
5.12.7
Многовалютность расчетов с поставщиками (возможность использования множества валют для расчетов с одним поставщиком)
5.12.8
Возможность автоматического расчета сумм платежей поставщикам исходя из условий оплаты
5.12.9
Контроль задолженности по поставщику с механизмом предупреждения
5.12.10
Занесение условий поставок по контрактам (сроки, номенклатура, количество, цены и т.п.)
5.12.11
Возможность расчета штрафных санкций за несоблюдение условий поставок, за задержку оплаты, анализ сроков оплаты и потерь
5.12.12
«История» поставщика и характеристики сотрудничества с ним
5.12.13
Информация о продажах по поставщикам (день продаж, период продаж, сумма, количество, товар, артикулы, поставщики товара, товарные группы / подгруппы и т.п.)
Итого по маркетингу
6. Стоимость и сроки внедрения
6.1
Стоимость 1 вариант ($)
6.1.1
Цена лицензии из расчета 300 пользователей (конфигурация определяется разделом требований со стороны бизнес – процессов):
- на каждого именованного пользователя
- на каждого одновременно работающего пользователя
- на каждое рабочее место (компьютер)
6.1.2
Итоговая стоимость лицензии
6.1.3
Стоимость технической настройки по результатам проектирования
6.1.4
Стоимость необходимых дополнительных программных продуктов
6.1.5
Стоимость обучения
6.1.6
Стоимость годового сопровождения
6.1.7
Средняя стоимость годовой технической поддержки
6.1.8
Ориентировочная стоимость аппаратного сервера (300 пользователей)
Итого по стоимости 1 вариант
6.2
Стоимость 2 вариант ($)
6.2.1
Цена лицензии из расчета 150 пользователей (та же конфигурация за исключением товародвижения и логистики):
- на каждого именованного пользователя
- на каждого одновременно работающего пользователя
- на каждое рабочее место (компьютер)
6.2.2
Итоговая стоимость лицензии
6.2.3
Стоимость технической настройки по результатам проектирования
6.2.4
Дополнительные затраты на интеграцию с модулями логистики
6.2.5
Стоимость необходимых дополнительных программных продуктов
6.2.6
Стоимость обучения
6.2.7
Стоимость годового сопровождения
6.2.8
Средняя стоимость годовой технической поддержки
6.2.9
Ориентировочная стоимость аппаратного сервера (150 пользователей с возможностью расширения)
Итого по стоимости 2 вариант
6.3
Стоимость 3 вариант ($)
6.3.1
Цена лицензии из расчета 100 пользователей (та же конфигурация только для товародвижения и логистики):
- на каждого именованного пользователя
- на каждого одновременно работающего пользователя
- на каждое рабочее место (компьютер)
6.3.2
Итоговая стоимость лицензии
6.3.3
Стоимость технической настройки по результатам проектирования
6.3.4
Дополнительные затраты на интеграцию с модулями логистики
6.3.5
Стоимость необходимых дополнительных программных продуктов
6.3.6
Стоимость обучения
6.3.7
Стоимость годового сопровождения
6.3.8
Средняя стоимость годовой технической поддержки
6.3.9
Ориентировочная стоимость аппаратного сервера (200 пользователей с возможностью расширения)
Итого по стоимости 3 вариант
6.4
Сроки внедрения
6.4.1
Ориентировочные сроки внедрения, 1 вариант
6.4.2
Ориентировочные сроки внедрения, 2 вариант
6.4.3
Ориентировочные сроки внедрения, 3 вариант
Итого по срокам внедрения
Технические требования к комплексным системам автоматизации предприятий
1. Требования к фирме-поставщику
1.1 Фирма-поставщик должна иметь большой международный опыт работы с промышленными предприятиями. Иметь успешные внедрения в производственной сфере, а также иметь успешные внедрения на российских предприятиях.
1.2 Фирма-поставщик должна иметь в России квалифицированные кадры для разработки и модернизации программного обеспечения, внедрения, сопровождения, технической поддержки и обучения.
2. Общие требования к системе
2.1 Система должна обеспечивать поддержку управленческих функций как в корпоративных масштабах (когда централизованно осуществляется финансовое и производственное планирование, учет и контроль), так и на решение задач в отдельно взятых производственных единицах, которые могут действовать или как полностью самостоятельные подразделения с автономным контуром управления, или составные элементы сложной холдинговой системы.
2.2 Система должна иметь возможность интеграции с функционирующими на предприятиях автоматизированными комплексами и задачами.
2.3 Иметь инструмент для разработки приложений, учитывающих особенности российского рынка.
3. Требования к техническим характеристикам
1. Программное обеспечение должно обладать открытой архитектурой «клиент-сервер» и иметь средства взаимодействия с другими программными продуктами.
3.2 Программное обеспечение должна иметь возможность работы в среде Intranet/Internet.
3.3 Программное обеспечение должно иметь многоплатформенную структуру, поддерживать различные операционные системы (Unix, NetWare,Windows NT), и работать с различными базами данных (Oracle, Informix, MS SQL Server, DB2 и другими). При этом должна быть предусмотрена возможность одновременной работы с различными базами данных, а также доступ к базе данных из любых приложений системы.
3.4 Система должна обладать свойством масштабируемости (легкостью расширения и сужения системы), обеспечивать работу пользователей через Интернет и иметь метаязыковые средства описания и настройки данных и процедур системы. Формирование информации верхних уровней должно происходить непосредственно из информации нижних уровней любого модуля, детализация информации должна быть возможна до источников любого нижнего уровня, любого модуля и любого филиала.
3.5 В системе должна быть предусмотрена возможность распределения приложений и баз данных, возможность резервного копирования и репликации данных. Обеспечение целостности данных должно выполняться автоматически.
3.6 Средства безопасности, используемые в системе, должны обеспечивать минимизацию риска некорректного использования или злоупотребления системой, а также разграничение полномочий пользователей по функциям. Доступ должен быть ограничен системой идентификации пользователя и пароля. В системе должен поддерживаться график аудита, обеспечивающий мониторинг каждого вхождения или попыток злоупотребления системой.
3.7 Программное обеспечение должно обеспечивать простоту внедрения и конфигурации информационной системы с помощью использования встроенных средств построения бизнес модели предприятия и автоматического формирования структур данных и экранных форм.
Требования к функциональности
Программное обеспечение информационной системы должно поддерживать выполнение полного комплекса интегрированных функций системы управления предприятием:
1. Управление финансовой и бюджетной деятельностью предприятия (составление финансового плана, планирование денежных потоков, бюджетирование расходов по центрам затрат, проектам и подразделениям, центрам ответственности, автоматическое формирование Российского и Западного балансов и приложений к балансу и др.);
2. Бухгалтерский учет и контролинг (ведение и подготовка выходных документов в соответствии с требованиями российского учета, детальный анализ баланса по подразделениям, буфер накопления проводок для ввода их в Главную Книгу с возможностью корректировки проводок в буфере, работа с «красным сторно», регистрация балансов дочерних компаний в отдельные базы данных (раздельные Главные Книги), консолидация балансов и др.);
3. Управление сбытом, снабжением и складами предприятия, планирование и учет товарно-материальных потоков предприятия (поступление и приходование на склад, со склада в цеховую кладовую, создание заказов на поставку и контроль за их выполнением, анализ товарооборота по подразделениям, товарным группам, учет запасов по изделиям в аналитике по секциям, складам, валютам, формирование отчетов по товарным запасам и товародвижению и др.);
4. Управление производством (дискретное и непрерывное производство различных типов – единичное, серийное, массовое, расчет нормативной и фактической себестоимости продукции, оперативное управление производственным процессом, моделирование производственных планов, создание и отслеживание выполнения планов производства и закупок, учет затрат машинного и рабочего времени, материалов на выполнение заказа – показано посменно в разрезе участков и оборудования и др.) и другие функции;
5. Планирование производственно-хозяйственной деятельности предприятия с учетом ограничений и приоритетов;
6. Управление инвестиционными проектами и капитальным строительством;
7. Управление транспортными задачами;
Управление сервисным обслуживанием и ремонтом оборудования;
8. Управление качеством продукции (соответствие стандарту качества ISO-9000).
Требования к базам данных
1. Система должна обеспечивать целостность и непротиворечивость данных и возможность распределенной обработки с использованием современных коммуникационных технологий (Интернет, e-mail).
2. Система должна обеспечивать разграничение доступа пользователей к данным и функциям системы.
3. Система должна обеспечивать архивирование, резервное копирование и восстановление данных.
4. Информационная модель Базы данных должна быть прозрачной и допускать разработку дополнительных приложений.
Требования к пользовательскому интерфейсу
Система должна иметь как алфавитно-цифровой, так и графический интерфейс. И иметь возможность оптимизации настроек для конкретного рабочего места.
Требования, предъявляемые на этапе внедрения
1. Система должна иметь встроенные средства построения бизнес модели предприятия и автоматического формирования структур данных и экранных форм.
2. Система должна иметь адаптированную к условиям российских предприятий методологию внедрения.
3. Система должна обеспечивать возможность быстрой перенастройки во время внедрения.
Требования к поддержке, сопровождению и обучению
Фирма-поставщик должна обеспечивать поддержку и сопровождение системы и иметь базу для обучения специалистов заказчика.
... назад | вверх | вперед ...
