Первая и основная проблема - это проблема понимания заказчиком исполнителя и исполнителем заказчика. В результате чего получается следуюшая картина.
Памятка руководителю проекта внедрения,
или "Как бороться с внедренцами?"
(данная памятка составлена в интересах заказчиков информационных систем)
▌От автора
"…Я старался написать памятку о том, как выявить недостатки системы и заставить внедренцев их исправить, как переложить риски внедрения на самих же внедренцев…"
▌Лучший отзыв оппонентов памятки
"…Памятка совсем стала похоже на руководство, как опустить на деньги компанию внедренцев в арбитражном суде…"
▌Введение
Памятка была опубликована в internet на сайтах www.erpforum.ru/forum и www.cfin.ru/forum и получила самые противоречивые отзывы от одобрения до негодования по поводу противопоставления заказчиков и внедренцев. Именно противопоставление, противостояние между заказчиком и внедренцем, отчасти проскальзывающее в памятке, было объявлено ее основным недостатком. Однако основной смысл памятки состоит все-таки в возможно более полном осмыслении требований к системе со стороны заказчика. Подобная позиция заказчика помогает внедренцам. Довольно часто бизнес заказчика неформализован и чем четче очерчены границы и возможности системы в самом начале проекта автоматизации, тем легче в дальнейшем и внедренцу, и заказчику. В Памятке предложены вполне конкретные шаги, которые может сделать заказчик для выявления своих требований и сравнения их с возможностями системы. Эти шаги изложены в простых, «земных» терминах – есть, к чему стремиться внедренцу, и ясно, чего ждать заказчику, - замечательный старт для внедрения информационной системы.
Получить и изучить демо-версию системы и документацию на систему, по возможности ознакомиться с практическим опытом эксплуатации системы на сходном предприятии. Можно также предусмотреть настройку некоего пилота под предприятие - это будет 3-4 человеко-месяца по трудозатратам, но выполнять эту работу бесплатно, естественно, внедренцы не будут.
Создать собственную группу внедрения, определить перечень ключевых пользователей системы. Эта группа должна быть создана приказом по предприятию, ключевые пользователи должны быть заинтересованы во внедрении и понимать, что не менее 30% рабочего времени они должны будут отдать внедрению.
Провести полноценное обучение ключевых пользователей работе в системе до закупки каких-либо модулей системы и до подписания контракта на внедрение системы. (Это позволит своевременно предъявить внедренцам требования на доработку системы или отказаться от внедрения неподходящей системы). Контраргумент: в общем неплохо, но для западной системы 1 человеко-день обучения - $100-300 без проезда и проживания. До подписания контракта потратить эти денежки ...
Проводить только поэтапное внедрение системы. Проводить только поэтапную закупку модулей и рабочих мест системы в соответствии с планом внедрения. За весь софт сразу платить нельзя, надо оплачивать только необходимые рабочие места. Это будет хоть какой-то рычаг давления на внедренцев: если не исправят ошибок в первом модуле, можно пригрозить не покупать следующие модули. Контраргумент: все бы хорошо, если бы модули были независимы друг от друга. В реалиях - они сильно "завязаны" между собой, внедрять только один, не учитывая при этом цепочку других, неправильно. А учитывать, не имея всех лицензий, не получится. Почему бы не разбить проект на этапы и платить Исполнителю поэтапно? Правда это тоже, скорее всего, не спасет. С одним можно точно согласится, что за весь софт платить нельзя, а необходимо проплачивать только необходимые рабочие места.
Оговорить пункт по приведению наименований всех полей на формах и в отчетах к терминологии, принятой на предприятии. Этот пункт позволит сразу выявить несоответствие понятий системы с реальностью заказчика. Контраргумент: однако, одним из плюсов стандартной приличной системы может быть привнесение передового бизнес-опыта. Да, не всегда это плюс, но есть ли уверенность в том, что ваша терминология правильна?
Оговорить состав передаваемой документации на систему, правила проверки и приемки документации.
Составить полный реестр выходных форм системы (первичных документов и отчетов), подготовить шаблоны выходных форм, правила формирования и образцы заполнения выходных форм. Утвердить правила проверки и приемки формирования выходных форм в системе. Фактически речь идет о разработке репозитория документов (база документационного обеспечения), который может дополняться на этапах информационной диагностики, в ходе разработки ТЗ и использоваться для анализа соответствия требований Заказчика возможностям системы. Контраргумент: замечательно, если реестр выходных форм вы сделаете сами до начала проекта! Этим вы экономите время внедренцам, а заодно и дадите им железный аргумент не делать более ничего! Если появится, а он наверняка появится, какой-то новый, но крайне необходимый отчет, все внедренцы как один скажут, что данная работа не входила в исходный перечень. Более рамочный договор позволит этого избежать, если заказчик достаточно грамотный. К тому же трудозатраты по созданию такого договора сравнимы с написанием ТЗ на весь проект. То есть это, собственно, и есть ТЗ.
Потребовать от внедренцев реестр уже готовых отчетов/первичных документов, которые уже есть в их системе и описание этих отчетов. Сравнить свой собственный реестр с реестром внедренцев.
Заранее оговорить все вопросы, связанные с импортом/экспортом данных. Сначала самим разобраться, а что конкретно мы хотим импортировать/экспортировать. Будет ли это разовая операция или лучше заказать постоянно действующую процедуру?
Не забыть согласовать ценовую политику: сколько стоит один отчет (или сколько стоит каждый из отчетов по реестру), сколько стоит передача в Excel одного первичного документа, сколько стоит импорт данных, сколько стоит исправление наименования одного поля на формах. Естественно, что все эти цены должны быть согласованы до оплаты лицензии за систему. Эти цены никогда не должны устанавливаться исходя из времени, которое на них тратят внедренцы. Цена всегда должна быть объявлена за конкретный отчет, первичный документ, процедуру импорта (идея ценовой политики: платить только за ощутимый результат, а не за час трудозатрат). Именно для того, чтобы установить четкие цены на эти работы и необходимо составить возможно более полные реестры и описания задач (внедренцам же надо будет как-то определится с ценой).
Разработать сквозные тестовые примеры работы с системой. Тестовый пример включает в себя полностью заполненные документы и порядок ввода/получения одних документов на основе других, перечень функций, которые должны выполняться системой.
Можно попробовать предусмотреть разработку тестовых примеров в качестве одного из результатов проведения диагностики предприятия. Не пожалеть денег на проведение диагностики, разработку тестовых примеров и обучение пользователей. (Диагностика - это то, что делают внедренцы за деньги заказчика перед тем, как сформулировать ему свои технические предложения. Самому заказчику от диагностики мало пользы, однако можно попробовать исправить это положение путем разработки тестовых примеров для дальнейшего использования при приемке системы).
Утвердить тестовые примеры у ключевых пользователей и внедренцев системы при подписании контракта на внедрение системы.
Тщательно продумать: кто и как будет осуществлять поддержку и сопровождение системы (имеются ввиду свои сотрудники). Подумать о курсах повышения квалификации для них, подключить их к работе по внедрению с самого начала проекта.
Предусмотреть возможность приобретения исходного кода системы (и поставку документации на русском языке, описывающей структуру данных и классы системы).
Оговорить наличие в системе "элементарных" удобств, таких как:
сортировка и двойная сортировка строк в таблице (в п.16 таблица - это grid, то, что видит пользователь),
фильтры строк в таблицах,
настройка скрыть/показать столбцов в таблице,
настройка ширины и порядка следования столбцов в таблице,
пользовательская настройка значений, подставляемых по умолчанию,
slavelookup-ные поля (lookup - это выбор из открывающегося списка, slavelookup - это поля, сопутствующие выбранному, например выбрали договор по его номеру, хотим сразу видеть его дату, тип и контрагента, причем всегда текущее актуальное значение сопутствующих полей),
автоматическое обновление данных на всех открытых формах системы (при одновременной работе нескольких пользователей с одними и теми же данными),
поиск (по несортированному списку), быстрый поиск (поиск ближайшего значения), поиск в "дереве", - копирование ячеек, - копирование строк в таблицах,
прямая вставка данных из Excel (из буфера обмена), настройка нескольких вариантов вставки из Excel (соответствие столбцов в таблицах системы и столбцов в Excel),
групповые операции по выделенному списку строк: удалить, изменить столбец, специальные групповые операции (например, провести, зарезервировать и прочее).
наличие в системе таких компонентов как: редактируемый grid, иерархический grid, иерархический lookup,
автоподбор lookup по текстовому значению, введенному с клавиатуры,
переход по lookup в связанную таблицу (на которую ссылаемся из данной таблицы),
хранение файлов в системе,
вставка файла путем перетаскивания файла мышкой из папок Windows в систему,
передать в Excel выделенные строки таблицы,
выделить все в таблице,
передача всех выходных форм в Excel,
возможность пользовательских настроек шаблонов выходных форм - цвет, шрифт, центрирование текста и прочее.
Оговорить в контракте возможность полной настройки прав доступа. Все виды прав (просмотр, добавление, изменение, запуск) на все элементы системы (таблицы, записи, функции). Контраргумент: эти возможности технически труднореализуемы и редко используются на практике.
Оговорить в контракте возможность ведения логов работы пользователей. Контраргумент: эти возможности редко используются на практике.
Оговорить в контракте возможность замены физического удаления записей на их аннулирование (логическое удаление), возможность просмотра истории изменения атрибутов системы. Контраргумент: эти возможности технически труднореализуемы и редко используются на практике.
Не следует забывать и о таких требованиях к системе, как масштабируемость, развиваемость (наличие встроенных средств разработки и модификации системы) и надежность.
Приемку системы осуществлять на основе подготовленных тестовых примеров, отдельно по следующим пунктам:
Приемка самой системы: форм для ввода и просмотра данных, функций, правильных наименований полей.
Приемка выходных (печатных) форм системы: отчетов и первичных документов, включая передачу в Excel, пользовательские настройки шаблонов документов.
Приемка документации на систему: руководства пользователя, руководства по администрированию системы, описание структур данных и классов системы. Контраргумент: обычно пишется "Программа и методика испытания", и далее по пунктам .…
Никогда не планировать разработку отчетов только на последнем этап внедрения системы. Каждый из этапов внедрения должен заканчиваться внедрением соответствующей отчетности. Естественно, что на таких этапах, как обследование или проектирование, говорить про внедрение отчетности еще преждевременно, но этапы, предусматривающие установку ПО, должны включать в себя и соответствующую отчетность.
Никогда не соглашаться на самостоятельную разработку всех отчетов и настройку форм по требованию пользователей. Контраргумент: вам выставят такие счета, что сразу захотите все сделать сами. (Чтобы не пострадать от ценового произвола внедренцев заранее оговорите цену отчетов, см. пункт 10).
Никогда не соглашаться на самостоятельное документирование системы. Дополнения: пока систему внедряют внедренцы, они ее и документируют, если в дальнейшем система модифицируется собственными силами, то и документировать придется самим.
Всегда требовать возможности последующей самостоятельной разработки новых и модификации существующих отчетов. (И пользоваться этими возможностями после передачи системы в промышленную эксплуатацию).
Ознакомиться с российскими ГОСТ на автоматизацию. Не смотря на то, что эти ГОСТ разработаны в конце 80-х, начале 90-х годов, и предназначены, скорее не для внедрения уже готовых систем, а для разработки и внедрения системы с «нулевого» цикла, в них, тем не менее, можно почерпнуть полезные идеи и применить их в своем проекте автоматизации. Перечень некоторых ГОСТ и ссылки на интернет-ресурсы по российским ГОСТ на автоматизацию приведены в конце Памятки.
Открыть в интернет дискуссию о ходе выполнения вашего проекта автоматизации, с тем, чтобы привлечь опыт информационного сообщества к вашему проекту и получить поддержку «бывалых» заказчиков. Открытая дискуссия о вашем проекте автоматизации – хороший стимул для внедренцев. В том случае, если проект будет успешным – они получат рекламу своей системы, а вот если ваш проект автоматизации пойдет со страшным скрипом или вообще провалится, то ваши публикации помогут другим потенциальным заказчикам избежать тех же ошибок. Одним из источников информации о недостатках системы являются интернет-форумы по данной системе. Иногда эти форумы бывают закрыты и заказчики получают к ним доступ только после приобретения системы, а не на этапе выбора системы или ее диагностики.
Уловка 1. Завышение цены диагностики.
Стоимость диагностики может оказаться существенно выше разумных пределов. Особенно круто возрастает стоимость диагностики при любой попытке вписать в результаты диагностики какой-либо пункт, кроме абстрактного отчета о диагностике или рекомендаций. Все эти отчеты и рекомендации у внедренцев уже есть в готовом виде, чуть-чуть подправил - и все готово. Другое дело составить реестр отчетов, подготовить шаблоны отчетов и их описание, не говоря уже про подготовку тестовых примеров работы с системой, которые в дальнейшем можно будет использовать при приемке системы. Но ведь именно пример работы системы может показать логику преобразования данных (например, из первичного документа в отчет), которая, в конечном счете, и требуется от системы. В такой ситуации можно посоветовать еще раз подумать о цене системы и ее ценности для предприятия. Если сама диагностика стоит так дорого, то сколько же будет стоить модификация системы и приведение ее в соответствие с требованиями заказчика? Можно так же применять различные схемы оплаты диагностики (50% сразу, 50% в случае подписания основного контракта). Часть работ по подготовке реестра и описания отчетов и разработке тестовых примеров придется поручить ключевым пользователям (бывает очень трудно объяснить людям, что это действительно важно, что на это надо тратить время, еще труднее убедить руководство предприятия выделить определенный объем времени для ключевых пользователей и оплатить их труд).
Комментарий: эта уловка получила неоднозначную оценку на форуме. Довольно трудно оценить объективную стоимость результатов диагностики.
Уловка 2. У нас есть методика, которая успешно применялась во многих проектах, давайте ее применять и в вашем проекте.
Идея применять проверенные методики заслуживает всеобщего одобрения, однако под этим флагом обычно пытаются протащить сокращение четкого описания бизнес-требований к системе. Например, согласно методике внедренцев, разработка тестовых примеров должна происходить уже после закупки лицензий. Зачем вам такая методика? Почему нельзя тестовые примеры работы системы разработать до закупки самой системы, ведь они просто отражают логику вашего бизнеса? Слепо верить методикам внедренцев - скользкий путь, так как, не имея показательных примеров, утвержденных в самом начале внедрения, на этапе приемки-сдачи очень трудно обоснованно предъявлять претензии внедренцам.
Комментарий: эта уловка получила следующие контраргументы на форуме: внедренцы могут иметь проработанные и вполне заслуживающие доверия сценарии внедрения. Некоторые внедренцы в ходе проекта разрабатывают методику реализации проекта, в которой формализуют все процедуры мониторинга проекта, анализа эффективности, порядка представления и сдачи отчетной, рабочей документации и т.д. В солидных компаниях-интеграторах это обычная практика! Кроме того, разработка тестовых примеров, отражающих логику вашего бизнеса - весьма дорогостоящее занятие.
Уловка 3. Мы выявим ваши бизнес-требования с помощью функциональных моделей, диаграмм потоков, формализованных описаний и пр.
Нет ничего плохого в построении функциональных моделей, диаграмм потоков и каких-либо иных формализованных описаний. Однако следует помнить, что все эти модели предназначены для профессиональных разработчиков программного обеспечения. Если вы считаете себя профессионалом в разработке ПО, то можете смело подписывать и утверждать все эти чудесные модели. А если вы (или ваши ключевые пользователи) являются профессионалами в другой области, то лучше просто принять участие в моделировании, но не подписывать эти модели. Ну как вы можете осознать, как та или иная стрелочка в IDEF/UML/ARIS/ER-модели скажется на работе системы? Будет ли это удобным? Бизнес-требования лучше выявлять на тестовых примерах (или экранных формах, прототипе системы), так как именно тестовые примеры вам наиболее понятны.
Комментарий: Эта уловка вообще не получила никаких отзывов в интернет-дискуссии.
Уловка 4. Если вы такие умные, то сами замечательно внедрите систему, да еще и денег сэкономите, а мы вас всему научим, мы вам все покажем.
Это откровенный обман. Нельзя научится внедрять современную ERP-систему, просто прослушав недельный курс обучения. После недельного курса обучения далеко не все ключевые пользователи смогут просто работать в системе, им потребуется время, чтобы, наконец, разобраться в обычном вводе данных и понять, как эти данные затем попадают в отчеты или используются в расчетных процедурах. Внедрение системы - действительно сложный процесс, которым должны заниматься профессионалы. Если вы все-таки решитесь на самостоятельное внедрение, то вам придется самостоятельно собирать команду внедренцев, причем только из тех людей, которые уже имеют опыт внедрения данной системы.
Комментарий: Эта уловка получила как положительные, так и отрицательные отзывы в интернет-дискуссии. По-видимому, это связано большим разнообразием систем автоматизации, обладающих различной степенью сложности. Чем больше сложность системы, тем меньше шансы на успешное самостоятельное внедрение системы.
Уловка 5. В нашей системе так много готовых отчетов, и, кроме того, есть специализированный построитель отчетов, так что не волнуйтесь, все нужные вам отчеты уже есть, а все остальные отчеты вы легко можете добавить самостоятельно.
Это тоже обман. Конечно, есть шанс, что некоторые из готовых отчетов подойдут и вам. Но это надо обязательно проверить до закупки лицензий. В конечном итоге, наличие реестра отчетов, согласованного с внедренцами, гораздо лучшая гарантия того, что эти отчеты действительно будут в системе. Дело в том, что структура хранения данных в системе может как позволять получать нужные вам отчеты, так и не позволять, если в процессе внедрения эта структура не была модифицирована в соответствии с вашими потребностями. Лучший способ проверки - просто получите из системы все отчеты при ее приемке. Если вы не убедились в наличии всех отчетов в системе - вы рискуете вообще никогда не получить нужных вам отчетов и никакой специализированный построитель отчетов вам уже не поможет.
Комментарий: Эта уловка получила только отрицательные отзывы в интернет-дискуссии, то есть такие уловки на практике не встречаются или исправляются путем приобретения внешних средств построения отчетности, таких как CristalReport или XL Report Builder.
Уловка 6. Вместе с нашей системой вы приобретаете весь мировой опыт организации бизнес-процессов да еще и в автоматизированном виде.
Верить этому нельзя. Это надо проверять. Так ли лучше этот самый мировой опыт, и вообще есть ли он в системе? Вполне может быть, что этот опыт не идет дальше красивых презентаций системы перед руководством предприятия. Сама презентация делается с одной целью - продать систему. Если, к примеру, с помощью системы предполагается осуществлять планирование закупок по новому принципу, то было бы неплохо задаться вопросом: а откуда берутся данные для этого, а правда ли, что мы реально (то есть в нашей реальной жизни) можем собрать эти данные в том самом виде, как этого требует система, а так ли легко модифицировать результаты планирования, то есть выполнять перепланирование. Может оказаться, что система умеет более-менее правильно планировать закупки/производство/сбыт, но в ней нет возможности оперативной АВТОМАТИЧЕСКОЙ коррекции этих планов, то есть, планируем автоматически, а затем вручную все корректируем, да еще и вручную обеспечиваем соответствие планов закупки с планом производства и пр. Трудоемкость коррекции может быть ОЧЕНЬ высокой.
Комментарий: Эта уловка получила положительный отзыв в интернет-дискуссии.
Уловка 7. Да вы поймите, говорят внедренцы, это не мы вам внедряем систему, вы сами ее внедряете, а мы вам помогаем, советуем, и вообще все делаем для вашего блага.
Внедрение ERP-систем - это бизнес, который далеко не всегда идет на пользу заказчикам. Зачастую руководители предприятий оказываются совершенно не компетентны в вопросах выбора и внедрения систем и становятся жертвами рекламных компаний, развернутых внедренцами. Практическое отсутствие четких, полных, документально оформленных требований к системе со стороны заказчика (заказчик просто не может их сформулировать) приводит к бесконтрольности действий внедренцев и ничем не ограниченной стоимости внедренческих работ. При этом оказывается, что заказчик, платя деньги за систему, становится жертвой собственных инвестиций. Он все больше и больше вязнет в проекте, так и не получая реально работающей системы. Когда стоимость затрат на лицензии и внедрение превышает все мыслимые пределы, внедрение останавливается, проект замораживается, а заказчик наконец-то начинает подсчитывать убытки. Наступает печальный момент, когда надо объяснить руководству, что несколько сотен тысяч долларов оказались неэффективно потрачены на систему. Что ж, такова цена бизнеса на глупости заказчиков. Если вы попались на эту уловку, то можете считать, что вы просто приобрели бесценный опыт и следующий проект автоматизации будет более удачным.
Комментарий: Эта уловка получила отрицательный отзыв в интернет-дискуссии. Заказчиков уверяют, что хуже им не станет.
Можно, к примеру, откорректировать эту памятку по собственному усмотрению и выслать ее потенциальным внедренцам, чтобы посмотреть, что они про все это скажут?
Соблюдение всех правил, перечисленных в памятке, в принципе возможно, но потребует от менеджеров таких затрат по времени, что вопрос целесообразности встает ребром. А потом еще и компетентность, которую можно встретить только в случае, когда директором предприятия становится бывший АСУ-шник.
Создается впечатление, что многое в памятке предназначено не столько для скорейшего эффективного внедрения системы, сколько именно для борьбы (или войны) с "подлыми внедренцами". Например, некоторые "элементарные удобства" из пункта 16 не во всех системах в принципе реализуемы (или реализация очень трудоемка), однако вряд ли их можно назвать жизненно необходимыми для работы системы. Однако "уперевшись" в такого рода пункты можно за деревьями не увидеть леса, то бишь возрастает вероятность ошибиться в выборе программы или превратить процесс внедрения в постоянные боевые действия. Впрочем, если подписать с внедренцами контракт, включающий все эти пункты, и, постоянно размахивая им как топором, периодически снисходительно идти на мелкие уступки, то, может быть, в этом и есть смысл.
В конечном итоге борьба с внедренцами - не единственная задача руководителя проекта внедрения. Однако не следует ни слишком увлекаться, ни пренебрегать перечнем задач, на которые в данной памятке рекомендуется обратить внимание.
Памятка может применяться и как средство давления на заказчика системы. Если заказчик согласился очень четко и детально описать свои требования с самого начала внедрения системы, то именно это он и получит в готовом виде. Ни больше, ни меньше, буква в букву как это написано в ТЗ. А умеете ли вы так четко и однозначно формулировать свои требования? Причем требования придется формулировать не на языке бизнес-логики, а в терминах самой системы, чтобы избежать их неоднозначного трактования (это касается в первую очередь описания функций и операций в системе, именно их труднее всего описывать на языке, понятном внедренцам)?
Памятка не содержит ничего нового, более того, в ней просто пропогандируется АСУшный подход 30 летней давности. Комментарий автора: можно вполне согласиться, что большинство пунктов памятки, или даже все ее пункты, итак всем известны, однако, публикуя и отставая такой подход к проектам автоматизации, я стараюсь убедить потенциальных заказчиков не в том, что эти пункты новы, а в том, что они правильны. Кроме того, я старался собрать возможно более полный комплект практических советов, чтобы постоянно помнить о них при подготовке к внедрению и при самом внедрении системы.
Создается впечатление, что памятка рассчитана на предприятие, которое не знает, зачем оно внедряет систему автоматизации. Однако подавляющее большинство предприятий четко понимают цели и задачи внедрения КИС и, в силу этого, многие пункты памятки не представляют для них никакого интереса.
Соблюдение вышеперечисленных пунктов, конечно, позволит своевременно выявить несоответствие системы нуждам заказчика, однако, в конечном итоге, внедренцы непобедимы. Ну не станут же они переделывать систему только потому, что она не соответствует потребностям конкретного заказчика. А добиться этого в полном объеме - сверхзадача даже для руководителя проекта внедрения.
▌Ключевые критерии успеха внедрения
Заинтересованность и поддержка высшего менеджмента.
Определённость целей и задач, которые должны быть решены в результате внедрения
Выбор системы исходя из потребностей предприятия (а не в результате откатов, функционала вообще, известности бренда и т.д.).
Грамотный выбор команды внедренцев.
Максимально четко прописанный план внедрения с описанием результатов каждого этапа (в данном случае чёткость означает не детальность, а именно очевидность формулировок, не допускающих двоякое трактование, а в случае возникновения такой двоякости позволяет уточнить, что именно имелось ввиду).
Создание на предприятии в результате внедрения собственной команды грамотных специалистов по системе.
Для крупных проектов: привлечение 1-2 внешних консультантов, которые будут выступать со стороны Заказчика и оказывать помощь в диалоге с командой внедренцев.
Привлечение руководства предприятия к управлению предприятием с помощью системы. Для любого проекта автоматизации это один из мощнейших факторов реального использования системы. Второй фактор использования системы – это удобство системы для пользователей. Оба эти фактора, к сожалению, реализуются не всегда
Проведение полноценной опытной эксплуатации системы. Опытная эксплуатация системы – это единственная доступная заказчику реальная проверка качества проектных решений, положенных в основу системы при ее настройке и модификации. Если в результате опытной эксплуатации будет установлено, что система не обеспечивает надлежащее качество поддержки бизнес-процессов предприятия, система должна быть повторно перенастроена и модифицирована.
▌Некоторые из российских ГОСТ на автоматизацию
ГОСТ 23962-80. Организация работ при создании систем.
ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы.
ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании автоматизированной системы.
ГОСТ 34.603-92. Виды испытаний автоматизированных систем.
РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов.
