Внедрение системы автоматизации управления, как и любое серьезное преобразование на предприятии, является сложным и зачастую болезненным процессом. Тем не менее, некоторые проблемы, возникающие при внедрении системы, достаточно хорошо изучены, формализованы и имеют эффективные методологии решения.
Итак, основные проблемы и задачи, требующие особого внимания при их решении:
Опишем эти пункты подробнее:
Отсутствие постановки задачи менеджмента на предприятии.
Этот пункт является наиболее значимым и сложным. Он является более глобальным и включает в себя не только методологию и философию управления, но также и психологические аспекты. Дело в том, что большинство руководителей управляют своим предприятием только исходя из своего опыта, своей интуиции, своего видения и весьма неструктурированных данных о его состоянии и динамике. Как правило, если руководителя попросить описать в каком-либо виде описать структуру деятельности своего предприятия или набор положений, исходя из которых он принимает управленческие решения, дело достаточно быстро заходит в тупик.
Грамотная постановка задач менеджмента является важнейшим фактором, влияющим как и на успех деятельности предприятия в целом, так и на успех проекта автоматизации. Например, совершенно бесполезно заниматься внедрением автоматизированной системы бюджетирования, если само бюджетирование не поставлено на предприятии должным образом, как определенный последовательный процесс.
К сожалению, на настоящий момент в России до конца не сложился национальный подход к менеджменту, и в данный момент российское управление представляет собой гремучую смесь из теории западного менеджмента (которая во многом не является адекватной существующей ситуации) и советско-российского опыта, который, хотя и во многом гармонирует с общими жизненными принципами, но уже не отвечает жестким требованиям рыночной конкуренции.
Поэтому, первое, что необходимо сделать для того, чтобы проект внедрения автоматизированной системы управления оказался удачным - максимально формализовать все те контуры управления, которые планируются автоматизировать. В большинстве случае, для осуществления этого не обойтись без привлечения профессиональных консультантов, но по опыту, затраты на консультантов просто не сопоставимы с убытками от проваленного проекта автоматизации. Однако нужно не ошибиться в выборе консультантов… Но это уже отдельный сложный вопрос.
Необходимость в частичной или полной реорганизации структуры и/или бизнес-технологии предприятия (реинжиниринг)
Прежде чем приступать к внедрению системы автоматизации на предприятии обычно необходимо произвести частичную реорганизацию его структуры и технологий ведения бизнеса. Поэтому, одним из важнейших этапов проекта внедрения, является полное и достоверное обследование предприятия во всех аспектах его деятельности. На основе заключения, полученного в результате обследования, строится вся дальнейшая схема построения корпоративной информационной системы. Несомненно, можно автоматизировать все, про принципу "как есть", однако, этого не следует делать по ряду причин. Дело в том, что в результате обследования обычно фиксируется большое количество мест возникновения необоснованных дополнительных затрат, а также противоречий в организационной структуре, устранение которых позволило бы уменьшить
производственные и логистические издержки, а также существенно сократить время исполнения различных этапов основных бизнес-процессов. Как сказал в свое время академик Глушков В.М., нельзя автоматизировать беспорядок, ибо в результате этого получится автоматизированный хаос. Под термином реорганизация не имеется в виду реинжиниринг в его классическом западном понимании, с частичной или полной перестройкой всей внутрихозяйственной и коммерческой деятельности. Реорганизация может быть проведена в ряде локальных точек, где она объективно необходима, что не повлечет за собой ощутимый спад активности текущей коммерческой деятельности.Эффективно построенная информационная система не может не внести изменений в существующую бизнес-технологию.
Во-первых, одними из самых важных для руководителя особенностей корпоративной информационной системы, являются модули управленческого учета и финансового управления. В результате эффективного внедрения каждое функциональное подразделение может быть определено как центр финансового учета, с соответствующим уровнем финансовой ответственности его руководителя. Это в свою очередь повышает ответственность каждого из таких руководителей, и предоставляет в руки высших менеджеров эффективный инструментарий для чёткого контроля исполнения отдельных планов и бюджетов.
При наличии информационной системы, руководитель способен получать актуальную и достоверную информацию обо всех срезах деятельности компании, без временных задержек и излишних передаточных звеньев. Кроме того, информация подаётся руководителю в удобном виде "с листа" при отсутствии человеческих факторов, которые могут предвзято или субъективно трактовать информацию при передаче. Однако справедливо было бы заметить, что некоторые руководители не привыкли принимать управленческие решения по информации в чистом виде, если к ней не приложено мнение человека, который ее доставил. Такой подход в принципе имеет право на жизнь и при наличии информационной системы, однако часто он негативно отражается на объективности менеджмента.
Внедрение системы автоматизации вносит существенные изменения в управление бизнес-процессами. Каждый документ, отображающий в информационном поле течение или завершение того или иного сквозного бизнес-процесса, в интегрированной системе создается автоматически, на основании первичного документа, открывшего процесс. Сотрудники, ответственные за этот бизнес-процесс лишь контролируют и, при необходимости, вносят изменения в позиции построенных системой документов. Например, заказчик разместил заказ на продукцию, который должен быть исполнен к определенному числу месяца. Заказ вводится в систему, на основании его системой автоматически создается счет (на основе существующих алгоритмов ценообразования), счет пересылается заказчику, а заказ направляется в производственный модуль, где происходит разузлование заказанного вида продукции на отдельные комплектующие. На основе списка комплектующих в модуле закупок системой создаются заказы на их закупку, а производственный модуль соответствующим образом оптимизирует производственную программу, чтобы заказ был исполнен точно к сроку. Естественно, в реальной жизни возможны различные варианты неустранимых срывов поставок комплектующих, поломки оборудования и т.д., поэтому каждый этап выполнения заказа должен строго контролироваться ответственным за него кругом сотрудников, которые, в случае необходимости, должны создать управленческое воздействие на систему, чтобы избежать нежелательных последствий или уменьшить их.
Не стоит полагать, что работать при наличии автоматизированной системы управления станет проще. Наоборот, существенное сокращение бумажной волокиты ускоряет процесс и повышает качество обработки заказов, поднимает конкурентоспособность и рентабельность предприятия в целом, а все это требует большей собранности, компетенции и ответственности исполнителей. Возможно, что существующая производственная база не будет справляться с новым потоком заказов, и в нее тоже нужно будет вносить организационные и технологические реформы, которые впоследствии положительно скажутся на процветании предприятия.
Сопротивление сотрудников предприятия
При внедрении корпоративных информационных систем в большинстве случаев возникает активное сопротивление сотрудников на местах, которое является серьезным препятствием и вполне способно сорвать или существенно затянуть проект внедрения. Это вызвано несколькими человеческими факторами: обыкновенным страхом перед нововведениями, консерватизмом (например, кладовщику, проработавшему 30 лет с бумажной картотекой, обычно психологически тяжело пересаживаться за компьютер), опасение потерять работу или утратить свою незаменимость, боязнь существенно увеличивающейся ответственности за свои действия. Руководители предприятия, принявшие решение автоматизировать свой бизнес, в таких случаях должны всячески содействовать ответственной группе специалистов, проводящей внедрение информационной системы, вести разъяснительную работу с кадрами, и, кроме того:
Именно в этом заключается "принцип первого руководителя", введенный академиком Глушковым В.М. и который кратко можно описать следующей метафорой: руководитель разработки должен иметь право ногой открывать дверь в кабинет первого руководителя предприятия.
Временное увеличение нагрузки на сотрудников при внедрении системы
На некоторых этапах проекта внедрения временно возрастает нагрузка на сотрудников предприятия. Это связано с тем, что помимо выполнения обычных рабочих обязанностей, сотрудникам необходимо осваивать новые знания и технологии. Во время проведения опытной эксплуатации и при переходе к промышленной эксплуатации системы в течение некоторого времени приходится вести дела, как и в новой системе,
так и продолжать ведение их традиционными способами (поддерживать бумажный документооборот и существовавшие ранее системы). В связи с этим, отдельные этапы проекта внедрения системы могут затягиваться под предлогом того, что у сотрудников и так хватает срочной работы по прямому назначению, а освоение системы является второстепенным и отвлекающим занятием. В таких случаях руководителю предприятия, помимо ведения разъяснительной работы с уклоняющимися от освоения новых технологий сотрудниками необходимо:Формирование квалифицированной группы внедрения и сопровождения системы, руководителя группы
Внедрение большинства крупных систем автоматизации управления производится по следующей технологии: на предприятии формируется небольшая (3-6 человек) рабочая группа, которая проходит максимально полное обучение работе с системой, затем на эту группу ложится значительная часть работы по внедрению системы и дальнейшему ее сопровождению. Применение подобной технологии вызвано двумя факторами: во-первых, тем, что предприятие обычно заинтересовано в том, чтобы у него под рукой были специалисты, которые могут оперативно решать большинство рабочих вопросов при настройке и эксплуатации системы, а во-вторых, обучение своих сотрудников и их использование, всегда существенно дешевле аутсорсинга. Таким образом, формирование сильной рабочей группы является залогом успешной реализации проекта внедрения.
Особенно важным вопросом является выбор руководителя такой группы и администратора системы. Руководитель, помимо знаний базовых компьютерных технологий, должен обладать глубокими знаниями в области ведения бизнеса и управления. В практике крупных западных компаний такой человек занимает должность CIO (Chief Information Officer) которая обычно является второй и в иерархии руководства компании. В отечественной практике, при внедрении систем такую роль, как правило, играет начальник отдела АСУ или ему аналогичного. Основными правилами организации рабочей группы являются следующие принципы:
Заключение
Все вышеперечисленные задачи, возникающие в процессе построения информационной системы, и методы их решения являются наиболее распространенными и естественно, каждое предприятие имеет свою уникальную организационную специфику, и при внедрении могут возникать различные нюансы, которые требуют дополнительного рассмотрения и поиска методов их решения. Собственно для этого и существуют профессиональные бизнес-консультанты.
Выводы:
Источники:
Каждой задаче из вышеизложенного перечня можно сопоставить похожий вариант, но относящийся к проблематике внедрения ИС. Перечислим их в том же порядке.
Примечание: Справедливости ради, должен сказать, что до сих пор не встречал ни одного универсального математического подхода к оценке экономической эффективности проектов внедрения ИС. Основная проблема оценки заключается в том, что ИС не способна напрямую повлиять на финансово-экономические показатели, а может лишь вовремя предоставлять нужную информацию руководителям и, тем самым, обеспечивать высокое качество управленческих решений. А верные и актуальные решения, в свою очередь, являются основной любого экономического подъема и увеличения конкурентоспособности.
Дополнительно хочу обратить ваше внимание на пятый пункт, который в данной классификации прекрасно олицетворяет тот факт, что любой программный комплекс может оцениваться только применительно к конкретной задаче и никоим образом не сам по себе. Дело в том, что очень многие руководители до сих пор серьезно заблуждаются, однобоко оценивая проблематику внедрения ИС. Важно четко отдавать себе отчет в том, что программное решение является лишь одним из кирпичиков будущей системы и работа по его конфигурированию и настройке это всегда необходимая, но не самая ответственная и рискованная часть проекта. Вне сомнения, у каждого серьезного разработчика (поставщика) имеются квалифицированные специалисты в этой области, способные успешно реализовать требуемую конфигурацию. Построение ИС – это серьезное изменение структуры предприятия, и обойтись без перепроектирования отдельных бизнес-процессов нереально (хотя бы в силу того, что ИС сама по себе подразумевает внедрение новых правил архивирования и обработки информации).
“Может ли ваша система автоматически управлять финансами?”
Из подслушанного на выставке…
Выбор ПК, или о том, как правильно читать маркетинговые материалы
Программные комплексы, предназначенные для внедрения в качестве базиса информационных систем, обладают одним общим характерным свойством: они сложны для оперативного ознакомления. Эта проблема обусловлена следующими факторами:
В качестве примера ниже приведены пять стандартных тезисов из маркетинговых брошюр разработчиков программных комплексов, а под ними расположена их трактовка, более соответствующая действительности или в большей степени отражающая информационное содержание.
“Наша система отвечает требованиям ERP-стандарта (класса)”
Программное обеспечение содержит функциональность, которая позволяет его использовать для построения комплексных информационных систем, включающих поддержку большинства направлений бизнеса (как минимум: управление финансами, управление производством и запасами и управление обслуживанием клиентов). Сразу необходимо уточнить, что ERP-стандарта (Enterprise Resource Planning) попросту не существует, и он относится к маркетинговым понятиям.
“Наша система отвечает требованиям стандарта MRPII”
В отличие от ERP, MRPII в некотором смысле является стандартом. Если выражаться точно, то MRPII (Manufactory Resource Planning) – это концепция управления производством и запасами, последняя её редакция (MRPII Standard System) была опубликована в 1989 г. американской ассоциацией управления производственными ресурсами APICS (http://www.apics.org). Следует отметить, что концепция MRPII является методологией менеджмента, а не софтверным понятием, несмотря на то, что возможность её применения на крупных предприятиях стала реальностью с прогрессом в области информационных технологий.
Итак, принадлежность решения к классу MRPII должна означать функциональную поддержку программным обеспечением выполнения следующего цикла: “планирование заказов -> планирование потребности в сырье и материалах -> планирование производственных ресурсов -> контроль над исполнением производственной программы -> обратная связь”.
Как показывает опыт, разработчики говорят о соответствии программного комплекса требованиям MRPII, когда существует какая-либо возможность планирования производственных ресурсов, а не только в тех случаях, когда поддерживается весь цикл. В первую очередь это касается отечественных софтверных компаний.
“Наша система является системой управления, а не системой учета”
Одно из самых спорных утверждений. Во-первых, программное обеспечение, как мы уже говорили, не является системой в рамках предприятия. И даже на базе самого продвинутого программного комплекса вполне можно построить систему, которая будет автоматизировать только бухгалтерский учёт. Но это только в качестве незначительного замечания.
Если смотреть глубже, нужно отметить, что основным управляющим фактором является процедура принятия решения, на основании результата которой осуществляется воздействие на систему (предприятие). ИС сама по себе решений не принимает, но, будучи эффективно настроенной, способна поставлять информацию руководителю в том ракурсе, который наиболее подходит для принятия конкретного решения. Вся информация (и плановая, и фактическая), которую формирует система в виде отчетов, составляется на основе учетных данных, поэтому говорить о разнице между “системами учета” и “системами управления” попросту бессмысленно.
Что касается использования на практике самого утверждения, то обычно программные комплексы считаются управленческими, если в них реализована функциональность для поддержки итеративной процедуры “планирование -> контроль -> анализ отклонений -> обратная связь”.
“Наша система имеет многолетний опыт успешных внедрений на Западе и обладает самым большим набором отраслевых решений.”
Действительно, многие зарубежные ПК имеют солидный и позитивный опыт применения на Западе. Однако не стоит забывать, что сами по себе подходы к управлению в нашей стране и на Западе существенно различаются. Например, в большинстве экономически развитых стран существуют и широко применяются на практике отраслевые стандарты менеджмента. Тем самым, западные тиражируемые ПК, как правило, подразумевают наличие общего стандартного регламента управления деятельностью предприятий, при этом, позволяя (благодаря широким возможностям по настройке) учитывать все индивидуальные особенности. То же самое можно отнести и к понятию “отраслевое решение”. Не секрет, что в СНГ (учитывая то, что соответствующий национальный менеджмент, как дисциплина, развивается чуть более 10 лет) практически не существует отраслевых управленческих стандартов (имеются в виду именно управленческие, а не технологические стандарты), и два предприятия, относящиеся к одной отрасли, могут принципиально различаться с точки зрения действующего управленческого регламента.
Несомненно, комплексные зарубежные решения применимы и у нас. Более того, при правильном подходе, их использование будет не менее продуктивным, чем на Западе. Однако, для того, чтобы их внедрение было успешным, всегда необходимо осуществлять реорганизацию бизнес-процессов, разрабатывать и утверждать регламент всех процедур и алгоритмов. Известно, что такой подход не является дешевым, однако ошибочно в целях экономии избегать его и вкладывать миллионы долларов в неэффективную информационную систему, пытаясь настроить подсистему производственного планирования в тех случаях, когда сама процедура планирования на предприятии не регламентирована и де-факто не существует.
“Наша система разработана в России (Украине) и наиболее всего подходит для автоматизации отечественных предприятий”
Большинство отечественных ПК изначально проектировались, как индивидуальные системы учёта в рамках конкретного предприятия, силами отдела АСУ, в режиме дефицита ресурсов и в отсутствии какой-либо методологии управления разработкой. С этим и связано большинство их недостатков. В целом же, типичные “узкие места” отечественных ПК выглядят следующим образом:
С точки зрения стоимости, отечественные решения выглядят привлекательно, однако, как показывает опыт, большинству из них (несмотря на громкие рекламные заявления) под силу автоматизировать лишь только некоторые базовые учетные функции, например: бухгалтерию, кассу, склад и расчёты с контрагентами.
С точки зрения технологического совершенства и полноты функциональной структуры, отечественные ПК значительно (а иногда безнадежно) отстают от западных собратьев, поэтому чаще всего являются применимыми на крупных предприятиях только в качестве заведомо временного решения.
При выборе ПК нужно всегда руководствоваться исходной постановкой задачи. Не стоит пытаться отвечать на возникающие вопросы самому, исходя из прочитанных маркетинговых брошюр. На конкретные вопросы, касающиеся применимости ПК в каждом случае должны отвечать специалисты поставщика, подтверждая каждый свой ответ соответствующей демонстрацией (показом действующей системы у других клиентов, настройкой контрольного примера и т.д.).
Особое внимание следует уделять предлагаемой поставщиком политике ценообразования на ПК. Обычно стоимость формируется исходя из количества приобретаемых лицензий на рабочие места по каждому из условных функциональных модулей. Иногда отдельно учитываются серверные лицензии по каждому дополнительному серверу приложений, включенному в итоговую конфигурацию. Если поставщик решения выступает в качестве внедряющей компании, нужно очень осторожно подходить к оценке предлагаемых комплексных вариантов, когда процентное соотношение стоимости продуктов и услуг может изменяться вариативно. Главное правило можно сформулировать следующим образом: любая схема ценообразования должна быть прозрачна и не должна использовать качественных факторов в качестве параметров расчета стоимости.
В заключение следует сказать, что выбор поставщика ПК целесообразно производить в режиме коммерческого тендера, что позволяет максимально объективно анализировать предложения и вести предметный диалог с потенциальными поставщиками.
“Дело должно соответствовать возможностям,
действия должны соответствовать времени”
Лао-Цзы
Управление проектом построения информационной системы
Произведем небольшой экскурс в историю минувших лет. Ажиотаж вокруг бурного прогресса в области информационных технологий со многими сыграл злую шутку. До конца не понимая ценности и характеристик конечного результата, наслушавшись “убедительных” речей системных интеграторов, а, иногда, просто желая “быть на уровне”, руководители большого количества предприятий начали инвестировать огромные средства в IT-проекты. Сначала фокус всеобщего интереса находился в области персональных компьютеров, потом переместился в сторону интегрированных сетей и, в конце концов, застыл на так называемых корпоративных информационных системах. Давайте, в качестве еще одной аналогии, вспомним, как изменялось всеобщее понимание о необходимости использования информационных технологий в рамках деятельности крупных предприятий. В качестве временного промежутка указан примерный период наивысшей активности компаний в реализации данного направления.
Результатом подобных иллюзий явилось огромное количество, как проваленных проектов, так и внедренных программных продуктов которые, несмотря на то, что функционируют на рабочих местах, нисколько не решают злободневных производственных и управленческих задач. Не напоминает ли это вам упоминавшуюся ранее компьютерную сеть, которая существует только ради факта своего существования?
Определение информационной системы приводилось в первом разделе, и, исходя из него, очевидна разница между понятиями “управленческий программный комплекс” и “управленческая информационная система”.
В подавляющем большинстве случаев проекты построения информационных систем традиционно начинаются с выбора программного комплекса. При этом, как правило, выбор происходит не на основе анализа соответствия решения требованиям заказчика, а исходя из оценки программного продукта самого по себе, что в дальнейшем способно повлечь за собой существенные проблемы.
Далее, в виде иерархической последовательности перечислены основные этапы проекта построения ИС. Стоит отметить, что рассматривается самый общий случай, когда управляющая (внедряющая) компания отличается от компании – поставщика ПК, как это принято на Западе при реализации крупных проектов. Такой подход имеет множество рациональных обоснований. Дело в том, что когда управляющая компания является одновременно и поставщиком программного решения, обычно она не может в полном объеме представлять интересы Заказчика в проекте, так как вынуждена в той или иной степени отстаивать “интересы” программного продукта. Подобная ситуация аналогична той, когда обоснование применимости или тестирование программного модуля поручают написавшему его программисту. С другой стороны, проект внедрения ИС никогда не должен носить софтверный оттенок, так как основной его целью является оптимизация управленческой инфраструктуры. Поэтому, проектным управлением должны заниматься не специалисты по конфигурированию ПК, а профессиональные бизнес-консультанты.
Итак, перечислим основные стадии проекта.
Выбор управляющей компании обычно играет решающую роль с точки зрения общей результативности проекта. Самые серьезные риски чаще всего обусловлены некачественным проектным менеджментом, поэтому ошибка в выборе управляющей компании может грозить серьезными неудачами. При анализе претендентов следует руководствоваться следующими главными факторами: наличие формализованной (отчуждаемой) методологии проектного управления, высокая деловая репутация компании, присутствие квалифицированных консультантов и бизнес-аналитиков, позитивный опыт работы в аналогичных проектах.
Почти во всех случаях проведения серьезных преобразований на предприятии возникает противодействие (как активное, так и пассивное) сотрудников на разных уровнях организационной иерархии. Это обусловлено характерной человеческой особенностью, выражающейся в опасениях по отношению к любым нововведениям, боязни утратить свою незаменимость, неготовности принимать решения и т.д. Как показывает практика, существенно уменьшить сопротивление персонала, а во многих случаях даже вызвать его заинтересованность в отношении проекта позволяет тщательная проработка новой политики мотивации труда. Другими факторами, эффективно сказывающимися на преодолении этой проблемы, являются: создание у сотрудников твёрдого убеждения неизбежности нововведений, поддержание высокого статуса проекта и закрепление всех проектных распоряжений соответствующими приказами руководства.
Обследование и реорганизация (в том случае, если она проводится) предприятия являются первым этапом проекта внедрения и их результаты определяющим образом влияют как на дальнейшую конфигурацию ИС, так и на соответствие результатов ожиданиям Заказчика. Поэтому уже на этом этапе всегда необходимо утверждать единую концепцию управления проектом и строго следовать ей на всех последующих стадиях, при необходимости внося в регламент коррективы, обусловленные новой предметной областью.
Как правило, любая проектная методология базируется на трех обязательных понятиях: модель команды, модель процессов и модель рисков. Модель команды определяет ролевой состав рабочей группы, правила взаимодействия между ролями и ответственность за выполнение проектных задач. Модель процессов описывает регламент выполнения работ, отчётную политику и правила предоставления результатов на протяжении всего жизненного цикла проекта. Модель рисков описывает правила выявления и отслеживания статусов рисков, а также принципы поиска решений по их устранению или плановому снижению последствий от их актуализации.
Очень часто случается, что этим этапом пренебрегают и, в результате, автоматизация не даёт никаких ощутимых результатов. Внедрение ИС оправдано лишь в тех случаях, когда деятельность предприятия соответствует стратегии развития и все методы управления, лежащие в основе требований по функциональности ПК уже имеют свой утвержденный регламент. Другими словами, нет никакого смысла покупать программный модуль “Бюджетирование” и внедрять его, если сама система бюджетирования на предприятии отсутствует. То же самое можно сказать об оперативности обработки и доставки управленческой информации. Если в этом процессе возникают ситуации, когда задержки вызваны организационными проблемами, то и при наличии ИС требуемой полноты и актуальности информации добиться невозможно.
Никогда не следует забывать о том, что если мы планируем внедрять ИС класса MRPII, то для начала нужно определиться с тем, как мы будем разрабатывать политику планирования производства с учетом новых условий, и уже потом разрабатывать техническое задание по конфигурации программного комплекса.
На самом деле, даже в тех случаях, когда поставщики ПК утверждают, что внедрение возможно по принципу “как есть”, они лукавят, так как всегда наличие ИС подразумевает новые методы работы с информацией, а соответственно и новую бизнес-модель предприятия. Только в этом случае изменения будут продиктованы конфигурацией ПК, а не реальными показателями эффективности бизнес-процессов.
Реорганизация бизнес-процессов является отдельной и очень обширной темой, актуальность которой отразилась в создании целых научных школ, поэтому в контексте этой статьи мы не будем детально рассматривать разнообразие подходов к организационному проектированию.
Конфигурирование и развитие ИС следует осуществлять в соответствии с принципом версионности. Длительность работ по созданию одной версии не должна быть очень большой (обычно не более года). Это связано со скоростью изменения бизнес-модели (связанной с развитием компании) и с прогрессом в отрасли информационных технологий. Подход к внедрению должен быть итеративным (циклическим): когда один цикл внедрения близок к завершению, должен планироваться следующий.
Процедуры управления конфигурацией обычно описываются в плане, либо в нем указывается ссылка на отдельный документ, который рассматривается как стандарт управления конфигурацией.
Обычно тестирование бывает двух категорий: функциональное и пользовательское. Целью функционального тестирования является максимально полная проверка каждого программного модуля на предмет сбоев. Для этой категории разрабатываются специальные типы тестов. Пользовательское тестирование - это следующий уровень тестирования, который выполняется, когда формальные контрольные примеры уже практически не выявляют ошибок. В этом случае, продукт тестируется путем имитации действий различных групп пользователей.
Риск всегда является неотъемлемой составляющей любого сложного и ответственного процесса. Более того, совершение рискованных действий необходимо для прогресса, а ошибки, как известно, являются основой приобретения опыта. Несмотря на то, что некоторые риски неизбежны, это не означает, что попытки определить их и управлять ими вредят творческой работе. Более подробно мы остановимся на процедуре управления рисками в следующей статье, а сейчас лишь отметим, что процедурное управление рисками на всем протяжении проекта является одним из самых главных факторов успеха.
Обеспечение качества готового продукта (версии) достигается нахождением оптимального баланса между тремя составляющими: функциональность, надежность, дата выпуска. Каждая из этих составляющих формируется на основе ожиданий заказчика. Очевидно, что не каждый проект является критичным к дате выпуска, так же как не каждый проект критичен к полноте реализации функциональности. Некоторые ошибки можно легко обойти путем изменения сценария действий пользователя, так как часто сохранение запланированного срока ввода продукта в эксплуатацию оказывается важнее, чем задержка из-за исправления ошибок и выполнения повторного тестирования.
Отметим дополнительно, что процесс управления проектом развития ИС является бесконечным: его динамика определяется темпом изменения всех составляющих системы и, в первую очередь, развитием бизнеса предприятия.
Источники: