Выбор СЭД: коробочное решение или заказная разработка?

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

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

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

Выбор коробочного ПП

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

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

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

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

Коробочные СЭД, как правило, имеют лицензию с ограниченным количеством рабочих мест или функций. Есть коробочные СЭД, которые имеют «облегченную» по функционалу бесплатную версию.

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

Существуют и принципиально другие коробочные СЭД-платформы, относящиеся к свободному программному обеспечению (СПО). Подобные СЭД-платформы предназначены для самостоятельной доработки и адаптации под требования организации-заказчика.

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

Словарь

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

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

Выбор СЭД: коробочное решение или заказная разработка?

Рис. 1. Схема распространения коробочных СЭД

Компания-разработчик коробочного ПО – компания, выпускающая полностью готовый для использования продукт со всеми инструкциями по подключению.

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

Организация-заказчик коробочного ПО – организация-потребитель ПО, которая может самостоятельно (через свою службу ИТ-поддержки) настроить и работать с коробочным продуктом или воспользоваться услугами дилера коробочного ПО.

Плюсы и минусы коробочных СЭД

Коробочные СЭД выпускают многие российские производители. И подобные решения имеют очевидные плюсы и минусы. Основной плюс коробочного ПО – уменьшение затрат на покупку по сравнению с заказной разработкой. Основной минус – отсутствие возможности изменять функционал системы.

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

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

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

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

 Разработчик коробочной СЭД не дает никаких гарантий, что данную СЭД или данную версию СЭД он будет в дальнейшем поддерживать (в том числе и устранять неисправности). В этом случае у пользователя коробочного продукта есть выбор: использовать данный продукт без усовершенствований (и без поддержки российского законодательства в том числе) или поменять его на другой продукт.

Ошибки при выборе коробочного ПП

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

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

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

Разработчики пытаются подстроить процессы заказчика под свою систему, обосновывая это различными убеждениями, начиная от того, что «так правильно», и заканчивая тем, что «система умеет только так и всем остальным это подходит». Конечно, существуют правила и рекомендации, как вести делопроизводство в организации (такие как ГСДОУ, ГОСТы и ОСТы), но как удобнее организовать данный процесс в конкретной организации, должны решать ответственные сотрудники непосредственно самой организации.

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

Важно знать!

Именно информационное обследование способно обеспечить правильный выбор коробочного ПО.

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

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

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

В противном случае процессы будут «подстраиваться» по ходу внедрения СЭД, и она будет постоянно вызывать негатив пользователей, т.е. неосознанно разрушать существующие процессы без их анализа.

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

Важно знать!

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

При создании концепции автоматизации обязательно должны быть описаны и проанализированы пути достижения экономического эффекта от внедрения СЭД. Результатом описания процессов «как должно быть» должны стать требования к функциям, которые будет автоматизировать СЭД. Только после этого можно переходить к выбору коробочного продукта.

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

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

Заказное программное обеспечение

Определение заказного ПО кроется в его названии – это программный продукт, который производится по заказу.

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

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

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

Существуют несколько способов и методов создания заказной СЭД. Наиболее распространенными являются два подхода к разработке:

  • каскадная (классическая разработка);
  • итерационная разработка.

Каскадная (рис. 2) (англ. waterfall model – «модель водопада») — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. На основе такой методологии построены российские стандарты и ГОСТы по созданию автоматизированных систем (34-й и 19-й серий), например,

ГОСТы 34 серии:

  • ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания";
  • ГОСТ 34.201-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем";
  • ГОСТ 34.602-89 "Техническое задание на создание автоматизированной системы";
  • ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных; систем";
  • ГОСТ 34.320-96 "Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы";
  • ГОСТ 34.321-96 "Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными".

ГОСТы 19 серии:

  • ГОСТ 19.001-77 "Единая система программной документации. Общие положения";
  • ГОСТ 19.101-77 "Единая система программной документации. Виды программ и программных документов";
  • ГОСТ 19.102-77 «Стадии разработки»;
  • ГОСТ 19.103-77 «Обозначения программ и программных документов»;
  • ГОСТ 19.104-78 «Основные надписи»;
  • ГОСТ 19.105-78 «Общие требования к программным документам»;
  • ГОСТ 19.106-78 «Требования к программным документам, выполненным печатным способом»;
  • ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению»;
  • ГОСТ 19.202-78 «Спецификация. Требования к содержанию и оформлению» и др.

Методические указания

  • РД-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы требования к содержанию документов».

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

Данная модель разработки хороша в следующих ситуациях:

  • при внедрении для проектов длительностью от нескольких недель до 2-3 месяцев, т.к. описанные требования не успевают устареть;
  • при внедрении систем, где нет подзадач и нескольких этапов разработки функционала (например, после разработки основного функционала СЭД нужно будет доработать ее взаимодействие с системой бухгалтерского учета, а требований к этому взаимодействию пока нет);
  • когда требования к создаваемой СЭД четко определены и зафиксированы.

Выбор СЭД: коробочное решение или заказная разработка?

Рис. 2. Каскадная модель разработки СЭД

  1. Итеративный, или итерационный подход (рис. 3) (англ. iteration — «повторение») — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. При этом разработка в каждой фазе развития проходит повторяющийся цикл итераций: Планирование — Реализация — Проверка — Оценка.

СЛОВАРЬ

Итерация (лат. iteratio — «повторяю») в широком смысле слова — термин, обозначающий повторение какого-либо действия, явления или процесса.

Данный подход получил большое распространение в США и на западе, где и был разработан. Известные на весь мир методики разработки ПО, такие как Rational Unified ocess (RUP) от компании Rational Software, придерживаются подобного подхода.

Основа данного подхода заключается в постепенном углублении функционала и требований и постоянном анализе созданного функционала вместе с заказчиком. При итерационном подходе на самых ранних сроках разрабатывается прототип СЭД для показа пользователям и получения обратного отклика об интерфейсе системы и подходе к реализации процессов.

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

Преимущества итеративного подхода

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

Выбор СЭД: коробочное решение или заказная разработка?

Рис. 3. Итерационная разработка ПО

Что же выбрать?

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

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

Е.С. Уланова, директор проектов, ЗАО "Центр новых технологий "Парус"

Анонсы будущих номеров
    Подробнее о журнале


    Ваша персональная подборка

      Подписка на статьи

      Чтобы не пропустить ни одной важной или интересной статьи, подпишитесь на рассылку. Это бесплатно.

      Рекомендации по теме

      Мероприятия

      Мероприятия

      Проверь свои знания и приобрети новые

      Посмотреть

      Самое выгодное предложение

      Самое выгодное предложение

      Воспользуйтесь самым выгодным предложением на подписку и станьте читателем уже сейчас

      Живое общение с редакцией
      Вебинар «Секретарь в соцсетях. Правила поведения»
      Журнал «Справочник секретаря и офис-менеджера»




      Вопрос - ответ

      Отвечаем на Ваши вопросы

      Какие реквизиты используются при оформлении приказов по основной деятельности?
      Проекты приказов по основной деятельности готовятся по поручению руководителя организации в структурных подразделениях организации, оформляются на специальном бланке и содержат следующие реквизиты
      Недавно устроилась секретарем в компанию, где передо мной встала задача наладить документооборот
      Подскажите, как правильно начать формировать локальную нормативную базу и какие нормативные документы мне в этом помогут? Читайте ответ на вопрос
      Задайте свой вопрос здесь>>> www.sekretariat.ru/pk

      PRO Делопроизводство
      Портал для руководителей служб ДОУ и секретарей всех уровней

      Все права защищены. Полное или частичное копирование любых материалов сайта возможно только с письменного разрешения редакции сайта. Нарушение авторских прав влечет за собой ответственность в соответствии с законодательством РФ.

      Зарегистрировано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор). Свидетельство о регистрации ПИ № ФС77-64197 от 25.12.2015


      E-mail: document@sekretariat.ru

      
      • Мы в соцсетях
      Сайт использует файлы cookie. Они позволяют узнавать вас и получать информацию о вашем пользовательском опыте. Это нужно, чтобы улучшать сайт. Если согласны, продолжайте пользоваться сайтом. Если нет – установите специальные настройки в браузере или обратитесь в техподдержку.
      Зарегистрируйтесь и продолжите чтение!

      Регистрация бесплатная и займет всего минуту!

      После регистрации вы сможете:

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

      У меня есть пароль
      напомнить
      Пароль отправлен на почту
      Ввести
      Я тут впервые
      И получить доступ на сайт Займет минуту!
      Введите эл. почту или логин
      Неверный логин или пароль
      Неверный пароль
      Введите пароль
      Всего один шаг - и документ Ваш!

      Только зарегистрированные пользователи могут скачивать материалы с сайта. Регистрация бесплатна и займет менее минуты. После нее Вы сможете загрузить документ, а также получите доступ к материалам и сервисам сайта.

      У меня есть пароль
      напомнить
      Пароль отправлен на почту
      Ввести
      Я тут впервые
      И получить доступ на сайт Займет минуту!
      Введите эл. почту или логин
      Неверный логин или пароль
      Неверный пароль
      Введите пароль