3) описание действий оператора при работе с программами (правила запуска программ, очередность работы, действия в возможных нестандартных ситуациях и т.д.).
Описание контрольного примера включает описание:
1) функций и параметров программного обеспечения, проверяемых контрольным примером;
2) состава технических средств, необходимых для проверки программного обеспечения на данном примере;
3) входной информации;
4) результатов прогона программ по данным контрольного примера;
5) действий оператора при проверке программы на контрольном примере;
6) результатов проверки (эталона контроля) программ на контрольном примере.
Порядок передачи программной документации
Все программы и инструкции, проверенные разработчиком на контрольном примере, сдаются заказчику по акту, удостоверяющему их приемку в опытную эксплуатацию.
Сдаваемые заказчику программное обеспечение, инструкции и описания алгоритмов должны соответствовать требованиям, предъявляемым к составу и содержанию рабочего проекта информационной системы. Заказчику передаются программы, записанные на магнитных носителях. Заказчик обеспечивает разработчика магнитными носителями и машинным временем, необходимыми для сдачи программ в опытную эксплуатацию и их дублирования (при необходимости).
Приемка комплекса задач (подсистем) в опытную эксплуатацию заключается в решении контрольного примера специально подготовленным персоналом заказчика в присутствии представителей разработчика с последующим анализом результатов. По взаимному согласованию контрольный пример может выполняться разработчиком в присутствии заказчика.
По результатам приемки подписывается акт сдачи-приемки программного обеспечения в опытную эксплуатацию. Обнаруженные
ошибки разработчика в программах и технической документации устраняются в процессе сдачи в опытную эксплуатацию.
Организационно-распорядительская документация
На основные работы, проводимые на стадии «Рабочий проект», оформляется следующая организационно-распорядительская документация:
1) приказ о проведении работ на стадии в соответствии с планомграфиком организационно-технических мероприятий;
2) план-график совместных работ исполнителя и заказчика;
3) акт проверки на контрольных примерах и приемки в опытную эксплуатацию рабочих программ;
4) акт готовности нормативно-справочной документации;
5) акт выполнения организационно-технических мероприятий по подготовке предприятия к внедрению информационной системы.
5.5. Ввод информационной системы в эксплуатацию
Ввод в эксплуатацию информационной системы и ее отдельных элементов представляет собой процесс постепенного переходы от существующих методов управления к методам автоматизированного управления.
Ввод в эксплуатацию информационной системы организуется и проводится силами заказчика при участии разработчика и организацийсоисполнителей. Взаимодействие организаций заказчика, разработчика и соисполнителей осуществляется на основании договорных условия и плана-графика сдачи информационной системы в промышленную эксплуатацию.
Ввод в эксплуатацию осуществляется поэтапно, начиная со стадии разработки технического проекта по мере готовности рабочей документации и ввода в эксплуатацию технических средств, обеспечивающих внедрение очередей или объектов информационной системы, способных к самостоятельному функционированию.
К вводу информационной системы в эксплуатацию следует приступать при наличии:
1) оформленных документов о выполнении плана мероприятий по подготовке объекта;
2) рабочей документации на внедрение выделенной очереди или информационной системы в целом;
3) обученного персонала, обеспечивающего подготовку к вводу в
эксплуатацию и эксплуатацию выделенной очереди информационной системы;
4) принятых в эксплуатацию технических средств информационной системы, обеспечивающих функционирование внедряемых комплексов задач.
Организация работ
Осуществляются:
1) опытная эксплуатация отдельных задач и их комплексов;
2) приемка комплексов задач в промышленную эксплуатацию;
3) проведение приемо-сдаточных испытаний;
4) приемка системы в промышленную эксплуатацию.
Состав и очередность выполнения работ определяются согласованными планами-графиками ввода в эксплуатацию, в которых указываются состав и сроки выполнения следующих работ:
1) по строительству, монтажу, наладке и испытанию объектов информационной системы с момента получения рабочей документации до сдачи объектов в промышленную эксплуатацию;
2) по проведению опытной эксплуатации и приемо-сдаточным испытаниям комплексов задач;
3) по обеспечению перехода от существующих методов управления
к методам, предусмотренным проектом информационной системы.
На стадии «Ввод информационной системы в эксплуатацию»
заказчик обязан :
1) завершить выполнение организационно-технических мероприятий по подготовке предприятия к внедрению информационной системы и оформить их актами;
2) обеспечить выполнение персоналом предприятия должностных и технологических инструкций;
3) ввести в эксплуатацию технические средства, необходимые для внедряемого технологического процесса обработки данных;
4) издать приказ с планом-графиком о проведении опытной эксплуатации информационной системы и проанализировать совместно с разработчиком результаты опытной эксплуатации;
5) завершить опытную эксплуатацию комплексов задач, входящих в состав информационной системы, и приемку их в промышленную эксплуатацию;
6) внести изменения в организационную структуру предприятия в соответствии с проектом информационной системы;
7) разработать проект приказа по составу приемочной комиссии;
8) разработать и согласовать с разработчиком проект программы приемо-сдаточных испытаний;
9) организовать работу приемочной комиссии, представить ей требуемую документацию и провести испытания информационной системы;
10) проверить эффективность реализованных решений в условиях промышленной эксплуатации и по результатам анализа функционирования системы разработать рекомендации по ее дальнейшему развитию.
На стадии «Ввод информационной системы в эксплуатацию»
разработчик обязан :
1) корректировать техническую документацию по результатам опытной эксплуатации информационной системы;
2) принимать участие в разработке проекта программы приемосдаточных испытаний информационной системы;
3) осуществлять методическое руководство и принимать участие в сдаче задач (комплексов задач) в промышленную эксплуатацию;
4) участвовать в работе комиссии по приемке информационной системы в промышленную эксплуатацию.
Порядок проведения опытной эксплуатации
Начало опытной эксплуатации задач (комплексов задач), сроки эксплуатации и состав комиссии по приемке конкретной задачи или подсистемы определяются приказом, изданным заказчиком и согласованным с разработчиком. К приказу прилагается согласованная с
разработчиком программа опытной эксплуатации, в которой определяются условия проверки комплексов задач, порядок проверки технических средств при решении комплексов задач (подсистем) и порядок устранения недостатков, выявленных при опытной эксплуатации.
Возникшие в процессе опытной эксплуатации дополнительные требования заказчика, не предусмотренные в техническом задании и техническом проекте, не являются основанием для отрицательной оценки результатов опытной эксплуатации и могут быть удовлетворены по дополнительному соглашению в согласованные сроки.
При положительных результатах опытной эксплуатации задач (подсистем) составляется двухсторонний акт о приемке их в промышленную эксплуатацию.
После приемки информационной системы в промышленную эксплуатацию ответственность за функционирование ее в объеме принятых комплексов задач и средств несет заказчик.
Исходные и отчетные документы при испытаниях программного обеспечения информационной системы
Совместные испытания проводятся комиссией заказчика, в которой участвуют руководитель разработки и некоторые ведущие разработчики. Комиссия при испытаниях руководствуется следующими документами:
1) утвержденным заказчиком и согласованным с разработчиком техническим заданием на создание информационной системы;
2) действующими государственными и отраслевыми стандартами на проектирование и испытание программного обеспечения и на техническую документацию;
3) программой испытаний по всем требованиям технического
4) методиками испытаний по каждому разделу требований технического задания.
Программа испытаний, методики их проведения и оценки
результатов разрабатываются совместно заказчиком и разработчиком и должны быть согласованы и утверждены. Они содержат уточнения требований технического задания для данной системы и должны гарантировать их корректную проверку. Документация на систему должна
полностью соответствовать испытываемым программам, обеспечивать познаваемость системы обслуживающим персоналом, а также обеспечивать возможность развития и модернизации программ для увеличения продолжительности их жизненного цикла.
Программа испытаний – это план проведения серии экспериментов. Он разрабатывается с позиции минимизации объема тестирования при заданной и согласованной с заказчиком достоверности получаемых результатов. Для этого определяются последовательность и объем каждого тестирования в процессе проведения испытаний для проверки выполнения требований технического задания при минимальных затратах. Особенно сложно бывает выбрать набор стрессовых ситуаций функционирования системы, при которых следует провести испытания.Программа испытаний должна содержать следующие четко сформулированные разделы:
1) объект испытаний , его назначение и перечень основных документов, определивших его разработку;
2) цель испытаний с указанием основных требований технического задания, подлежащих проверке, и ограничений на проведение испытаний;
3) собственно программу испытаний , содержащую проверку комплектности разработанной системы в соответствии с техническим заданием и план тестирования для проверки функционирования программ по всем разделам технического задания и дополнительным требованиям, формализованным отдельными решениями;
4) методики испытаний , однозначно определяющие все понятия проверяемых характеристик, условия тестирования, средства, используемые для испытаний, методики обработки и оценки результатов тестирования по каждому разделу программы испытаний.
Большой объем разнородных данных, получаемых при испытаниях
программного обеспечения, и разнообразие возможных способов их обработки, интерпретации и оценки приводят к тому, что важнейшими факторами для обработки результатов тестирования становятся методики обработки и оценки результатов . В соответствии с методиками испытаний средства автоматизации должны обеспечивать полноту проверок характеристик по каждому разделу методик и разработку
протоколов проверки по пунктам программы испытаний. Сложность программного обеспечения и тесная взаимосвязь между различными его характеристиками приводят к необходимости тщательной формулировки всех условий тестирования и значений параметров, при которых должна производиться проверка.
Результаты испытаний фиксируются в протоколах, которые обычно содержат следующие разделы:
1) назначение тестирования и раздел требований технического задания, по которому производится испытание;
2) указание методик, в соответствии с которыми проводились испытания, обработка и оценка результатов;
3) условия проведения тестирования и характеристика исходных
4) обобщенные результаты испытаний с оценкой их на соответствие требованиям технического задания и другим руководящим документам;
5) выводы о результатах испытаний и степени соответствия созданного программного обеспечения определенному разделу требований технического задания.
Протоколы по всей программе обобщаются в акте, в результате чего
делается заключение о соответствии системы требованиям заказчика и о завершении работы с положительным или отрицательным итогом. При полном выполнении всех требований технического задания заказчик обязан принять систему и работа считается завершенной.
Однако, как уже отмечалось, для сложных комплексов программ трудно на начальных этапах проектирования предусмотреть и корректно сформулировать все требования технического задания. Поэтому при отладке и испытаниях часто выявляется, что некоторые требования технического задания оказываются невыполненными и иногда даже принципиально не могут быть выполнены при самом добросовестном отношении к этому со стороны разработчика. В этом случае необходима совместная работа заказчика и разработчика в поисках компромиссного решения при завершении испытаний и составлении заключения. Некоторые недостатки комплекса программ в процессе испытаний только регистрируются и фиксируются в плане устранения замечаний комиссии,
проводившей испытания. Этот план является приложением к акту о результатах испытаний и позволяет отделять последующие доработки от непосредственных испытаний.
Порядок проведения приемо-сдаточных испытаний
Ответственность за организацию и проведение приемки в промышленную эксплуатацию несет заказчик. Приемка информационной системы в промышленную эксплуатацию производится по завершению приемки заказчиком всех комплексов задач (подсистем) в промышленную эксплуатацию.
Задачи, комплексы задач (подсистем) и технические средства информационной системы, не предусмотренные в техническом задании, но внедренные заказчиком самостоятельно, могут быть включены в комплекс сдаваемой информационной системы только по согласованию с разработчиком и после внесения в техническое задание на создание информационной системы соответствующих изменений.
По требованию заказчика или разработчика к приемке информационной системы могут быть привлечены представители субподрядных организаций.
Заказчик предъявляет информационную систему приемочной комиссии. Помимо членов комиссии к приемке могут привлекаться с правом совещательного голоса эксперты по отдельным вопросам создания информационных систем. Заказчик обязан обеспечить нормальные условия работы комиссии в соответствии с принятой программой приемки информационной системы. Для оперативного решения организационных вопросов, возникающих в процессе приемки информационной системы, приказом руководителя организации-разработчика выделяется ответственный представитель от организации-разработчика.
Заказчик совместно с разработчиком подготавливает проект программы проведения испытаний и приемки информационной системы и передает его приемочной комиссии для рассмотрения и утверждения. В программе указываются: наименование сдаваемой информационной системы, директивные документы, на основании которых разрабатывалась система (если такие имеются), состав приемочной комиссии и номер приказа о ее назначении, цель, объекты, объем, место и
последовательность испытаний, методика проведения испытаний и оценки результатов.
Заказчик подготавливает совместно с разработчиком и передает во временное пользование комиссии следующие документы:
1) приказы, распоряжения, планы, договоры, предусматривающие создание информационной системы;
2) технико-экономическое обоснование, техническое задание, технический проект, рабочий проект информационной системы;
3) акты рассмотрения и утверждения технического проекта;
4) двухсторонние акты заказчика и разработчика по сдаче задач, комплексов задач (подсистем), устройств и их комплексов в промышленную эксплуатацию в соответствии с утвержденным техническим заданием.
Приемочная комиссия обеспечивает:
1) проверку документации и функционирования информационной системы;
2) организацию рабочих групп и распределение обязанностей среди членов комиссии для проверки отдельных подсистем;
3) проверку расчета экономической эффективности созданной информационной системы;
4) организацию рабочих совещаний и подготовку актов приемки информационной системы.
Проверка условий эксплуатации и режима работы технических
средств информационной системы проводится одновременно с проверкой функционирования комплексов задач (подсистем). Подготовленность персонала, ответственного за функционирование информационной системы, определяется в соответствии с программой обучения и должностными инструкциями, входящими в состав рабочего проекта. Результаты проверки обсуждаются на рабочих совещаниях и оформляются протоколами.
Завершающим этапом работы комиссии является составление акта, в котором указываются:
1) состав комиссии, должности и места работы членов комиссии;
2) срок (дата) приемки системы;
3) состав исполнителей (организаций, предприятий), принимавших участие в создании информационной системы;
4) основания для проведения приемки (приказы, распоряжения и
5) перечень предъявленной документации информационной системы
и оценка ее соответствия действующим нормативно-техническим документам;
6) соответствие фактически выполненных и внедренных работ техническому заданию;
7) готовность всех видов обеспечения и структурных подразделений заказчика к внедрению и эксплуатации информационной системы;
8) сведения об эффективности информационной системы (сопоставление имеющихся или ожидаемых фактических данных по объему и источникам получаемой экономии с расчетными данными);
9) выводы комиссии о возможности приемки информационной системы;
Акт приемки в пяти экземплярах подписывается председателем и всеми членами комиссии. Датой ввода информационной системы в эксплуатацию считается дата подписания акта комиссией.
6. Коллектив разработчиков информационных систем
Поскольку создание современной информационной системы – сложный процесс, требующий совместных усилий большого числа различных специалистов, формирование коллектива, занимающегося проектированием, разработкой и внедрением информационной системы, в современных условиях приобретает очень большое значение.
Организация коллектива и распределение работ по специалистам могут производиться по нескольким принципам:
1) на основе распределения системного анализа (алгоритмизации) и разработки программ по разным коллективам;
Система управления ИТ: три составные части …
В контексте этого номера под системой управления ИТ мы будем подразумевать автоматизированную систему управления деятельностью ИТ-подразделения, построенную на базе специализированных подходов, методологий, стандартов и программных решений для ИТ-отрасли. Концептуальной основой построения такой системы является «сервисный подход», то есть организация управления ИТ-службой как сервисным подразделением и ориентация всей работы персонала на предоставление услуг бизнесу. Поэтому такая система управления часто называется «Системой управления ИТ-услугами», а ее внедрение – «Внедрение ITSM-решения» или «ITSM-проект».
Система управления ИТ, конечно, не ограничивается средствами автоматизации. Конечный результат ITSM-проекта – работающая система управления ИТ «под ключ». Это совокупность трех составляющих – «процессы», «люди», «средства автоматизации». Когда мы говорим о коммерческом внедрении или об оказании услуг по внедрению, все эти составляющие, как правило, включаются в договор с исполнителем (системным интегратором, консалтинговой компанией) в качестве формальных объектов поставки.
«Процессы» – это так называемая процессная документация, то есть целый комплекс организационно-распорядительных документов, описывающих и устанавливающих правила работы персонала ИТ-подразделения, области ответственности и порядок взаимодействия. Концептуальная основа современной системы управления ИТ (наряду с уже упоминавшимся сервисным подходом) – это процессное управление в сочетании с отраслевой моделью, описанной в библиотеке ITIL. Конкретный ITSM-проект охватывает один или несколько взаимосвязанных процессов, для которых и разрабатывается процессная документация.
«Люди» – это сотрудники ИТ-подразделения, которые участвуют в процессе внедрения, а затем становятся пользователями системы. Они являются носителями опыта и знаний о специфических технологиях и практиках организации и вносят существенный творческий вклад в дизайн системы.
«Средства автоматизации» – это комплекс технических и программных средств, автоматизирующих деятельность в рамках процессов. Мы не будем уделять особого внимания самим программным средствам, скажем лишь, что на современном рынке представлено немало специализированных отраслевых программных решений.
Для компании «Инфосистемы Джет» флагманскими решениями являются (в алфавитном порядке) линейки продуктов «BMC Remedy ITSM Suite» и «HP Software Service Management Center». Таким образом, внедрение ITSM-решения – это целенаправленное изменение трех составляющих системы управления ИТ: нормативной документации, навыков работы персонала и средств автоматизации для ограниченного числа видов деятельности (процессов). После принятия принципиального решения о необходимости изменения системы управления ИТ (запуске ITSM-проекта) начинается стадия планирования. Здесь устанавливаются ключевые параметры проекта, выделяются его составные части (задачи), определяется необходимый объем ресурсов, последовательность проведения работ, устанавливается бюджет.
На этом этапе организация принимает ряд важных решений. В первую очередь: какими силами реализовать проект, самостоятельно или с привлечением консультантов? Какое программное обеспечение использовать? Для ответа на эти вопросы в помощь организации имеется достаточное количество источников, в том числе – исследования, рейтинги и отзывы владельцев подобных систем. Распространенными инструментами поиска наилучших решений являются запрос технико-коммерческих предложений ведущих интеграторов, организация технических презентаций и демонстраций от различных вендоров, запуск «пилотных» проектов для сравнения платформ.
При тщательном подходе организаций к планированию в части выбора программных средств и команды исполнителей, в большинстве случаев остается за кадром технологический аспект планирования проекта: что будет взято за основу создаваемой системы, в какой степени и каким образом эта основа будет доработана для получения конечного результата. Как правило, вопрос выбора способа разработки и внедрения на этапе подготовки проекта не ставится явным образом, этот способ как бы скрыт внутри детальных планов проекта и остается на усмотрение исполнителя.
По нашему мнению, недостаточно четко обозначенный выбор способа разработки влечет за собой высокие риски неустранимых отклонений от плана (то есть тех, которые требуют сущест-венного перепланирования и уточнения составных частей проекта). Снизить влияние таких рисков поможет открытое обсуждение и согласование ожиданий заказчика и исполнителя относительно способа внедрения.
При всем разнообразии платформ и богатстве функциональных возможностей, представленных на рынке специализированных программных средств «промышленного» класса, организация имеет в своем распоряжении всего три альтернативных способа использования их для построения системы управления. Назовем их условно: «Решение от производителя», «Лучшая практика» и «Индивидуальное решение».
«Решение от производителя» – установка системы автоматизации «из коробки» и начало работы по эталонным технологическим схемам производителя (с последующей донастройкой в процессе сопровождения). Это наиболее быстрый и недорогой способ организовать работу по-новому.
«Лучшая практика» – установка типового решения, заранее созданного компанией-интегратором на основе своего опыта. Это наиболее гарантированный способ получить реально работающую систему.
«Индивидуальное решение» – разработка индивидуального решения, начиная с процессной модели и регламентов процессов и заканчивая особенностями настроек интерфейсов пользователей. Такой способ лучше всего позволяет учесть пожелания сотрудников и имеющиеся в организации наработки.
При выборе решения от производителя организация получает систему автоматизации с преднастроенной бизнес-логикой и документацию, входящую в стандартный комплект поставки лицензий. Работы интегратора по настройке такого решения включают установку и тестирование на комплексе технических средств заказчика, ввод справочных данных о размещении объектов обслуживания, организационной структуре, сервисах, пользователях. Также производится интеграция с почтовой системой для отправки оповещений. Этого, как правило, достаточно, чтобы начать обучение сотрудников и эксплуатацию системы управления.
«Лучшая практика» (авторское решение компании-интегратора) обеспечивает, как минимум, удобный, не перегруженный пользовательский интерфейс и достаточный для работы набор автоматизированных функций. Помимо инсталляции и заполнения справочников, внедрение такого решения подразумевает некоторую адаптацию процессной документации и доработку системы автоматизации, в основном, средствами настройки, а не программирования. Ключевые предпосылки успешного внедрения: верная оценка применимости для конкретной отрасли и заказчика, наличие простого и красивого интерфейса, высокое качество документации и надежность функционирования.
Первые два варианта («решение от производителя» и «лучшая практика») имеют много общего. Это готовые решения, которые в рамках проекта не разрабатываются. Внедрение их, по сути, начинается с развертывания и обучения. Планы внедрения таких решений разработаны заранее, много раз апробированы и от проекта к проекту не меняются. Если организация пошла по одному из этих вариантов модернизации системы управления, самые критичные вопросы проекта – это вопросы выбора правильного производителя (платформы) и правильного интегратора.
Наименее предсказуемым и поэтому более интересным для рассмотрения с точки зрения участников проекта представляется «Индивидуальное решение», в рамках внедрения которого происходит, в первую очередь, проектирование и разработка специфичной для конкретной организации системы. Проекты внедрения индивидуальных решений могут существенно различаться по стоимости и срокам. По нашему опыту наиболее существенным фактором здесь является способ организации проекта.
В качестве методологической основы проектирования и внедрения индивидуальных решений, в общем случае, используются стандарты управления проектами, стандарты и базовые нормативные документы управления жизненным циклом программных средств, а также методологии проектирования программных средств от известных производителей (Microsoft, Oracle, HP, BMC и др.). На их основе компания-интегратор формирует свой собственный профиль стандартов и методик, регламентирующий процессы проектирования, разработки, эксплуатации и развития информационной системы. Все эти стандарты и методики адаптируются и конкретизируются применительно к определенным классам проектов, в нашем случае – к ITSM-проектам.
Рис. 1. Карта продуктов
В результате получается набор конкретных методических указаний, требований, свойств и показателей качества, характеризующих способ организации разработки и внедрения системы. Другая часть характеристик индивидуального решения – в основном, функциональные и технические – творчески определяется заказчиком и исполнителем уже в процессе разработки.
Таким образом, даже для индивидуального решения на стадии планирования проекта значительная часть проектных решений предопределена и известна исполнителю. Поэтому имеет смысл поставить обсуждение способа разработки в один ряд с такими вопросами подготовки проекта, как выбор платформы (вендора) и выбор архитектуры.
В какой последовательности будут получены результаты проекта? Как будут сформированы и собраны замечания заказчика? В каком порядке и в каком объеме замечания будут приняты и устранены? Эти и другие вопросы, характеризующие применяемый исполнителем способ организации проекта, могут быть поставлены
на этапе планирования в том числе и для того, чтобы более точно сравнить конкурентные предложения и выбрать наилучшее.
Основной вопрос способа разработки: каким образом мы получаем продукты проекта? Для того чтобы понимать это самим, рассказать об этом заказчику, и, самое сложное, реализовать задуманное, мы используем карты продуктов проекта. Карта продуктов – это схема промежуточных и конечных результатов проектных работ, определяющая, что и в каком порядке будет производиться в ходе проекта (см. ). Методической основой построения карты продуктов является метод «Планирование на основе продуктов» (Product based planning) из Prince2, используемый для разработки «Структурной декомпозиции работ» (Work breakdown structure).
Наши карты «расчерчены» этапами проекта, на которые в виде прямоугольников наносят продукты проекта. Прямоугольники соединяются связями, связи определяют, на основе каких продуктов разрабатываются следующие продукты. Таким образом, карта продуктов определяет технологию изготовления системы управления.
Все продукты могут быть разделены на две группы. Первая группа – «внешние», которые предоставляются заказчику. Вторая – «внутренние», которые необходимы проектной команде как технологическая составляющая, как правило, для того, чтобы получить один из «внешних» продуктов.
У нас применяется еще одна классификация продуктов: «обязательный» и «опциональный». К «обязательным» относятся продукты, разработка которых необходима с технологической точки зрения (без них конечный результат ITSM-проекта не получить). К «опциональным» относятся продукты, без которых можно было бы обойтись. «Опциональные» продукты включаются в карту продуктов, как правило, по требованию заказчика.
Состав, последовательность и взаимосвязи продуктов, составляющие основную ценность карты, определены эвристически, вряд ли возможно представить универсальный алгоритм составления такой карты. Это результат многолетнего опыта внедрения, огромного количества ошибок, принципиальных идеологических споров, внезапных открытий, проб, прошедших испытание временем и реальными проектами.
На основе карты продуктов можно наглядно показать основные отличия и особенности рассматриваемого способа разработки. Большинство реализованных нами проектов может быть отнесено к одному из двух способов организации работ. Назовем их условно «Классический» и «Итерационный» и рассмотрим каждый отдельно.
Каждый пример продукта в статье описан по следующей схеме:
- Форма;
- Назначение;
- Содержание;
- Варианты, рекомендации.
Суть «классического» способа внедрения – по-этапная разработка системы, начиная с исследования предметной области и заканчивая внедрением системы «под ключ» и дальнейшим сопровождением. Мы выделяем (и наносим на карту) следующие этапы проекта:
В случае «классического» способа внедрения этапы очень важны, так как получаемые в конце этапа результаты (продукты проекта) кладутся в основу следующего этапа, и их пересмотр практически невозможен без внесения изменений в проект. Рассмотрим основные продукты проекта на каждом из этапов.
Цели у этапа обследования две: получить представление о текущей практике в предметной области и уточнить постановку задачи. Основной результат этапа – отчет об обследовании. Если следовать карте, первый продукт этапа – «Структура объекта управления» (другое название – «Модель обследования»). Заказчику он не выдается, это «внутренний» продукт. В нем, по той же схеме «люди – процессы – средства автоматизации», фиксируется: что нужно исследовать в рамках обследования, какие документы получить и изучить, с какими людьми провести интервью, какие средства автоматизации, используемые заказчиком, рассмотреть.
Отчет об обследовании
Форма
Текстовый документ (преимущественно), презентация.
Назначение
Отчет об обследовании является наиболее любопытным и интересным для чтения проектным документом. В начале проекта отчет полезен для создания атмосферы взаимопонимания в совмест-ной проектной группе «Заказчик – Исполнитель»: консультанты демонстрируют понимание специфики и приоритетов организации, а представители заказчика принимают и соглашаются использовать термины и инструментарий ITSM-проектов, например, «ролевая структура процесса» и «уровень зрелости».
Вторая жизнь «Отчета» начинается в конце проекта, когда требуется продемонстрировать эффект от внедрения новой системы (было – стало). В дальнейшем, после запуска системы управления в эксплуатацию, он становится ненужным и практически не используется.
На основе чего разрабатывается
Консультанты составляют отчет на основе своих заметок, сделанных в ходе интервью, а также на основе собранных документов организации: положений, инструкций и так далее. Точность и качество пропорциональны квалификации консультантов и их количеству на интервью (один консультант – плохо). Если в ходе обследования проводилось анкетирование (что бывает не каждый раз), результаты обрабатываются и попадают в отчет в агрегированном виде.
Типовой отчет условно делится на три основных блока: общие сведения, описание текущей ситуации, выводы.
Общие сведения – это заявленные цели обследования, границы обследования (организационные и функциональные), перечень используемых документов и интервьюируемых лиц. Здесь же приводится описание методики обследования, включая методы сбора информации, методы группировки и обобщения, методы и критерии оценки.
Описание текущей ситуации – это структурированное изложение текущей практики «как есть», иногда с использованием графических схем и рисунков. Для всех обследуемых областей деятельности организации используется единая структура описания. Например, такая:
- Организационная и ролевая структура;
- Виды деятельности процесса;
- Документационное обеспечение;
- Информационное обеспечение;
- Средства автоматизации.
Часто в раздел включаются требования руководства и собранные в ходе обследования пожелания по улучшению, по возможности, без изменения формулировок.
В разделе «Выводы» содержатся результаты анализа текущей ситуации. Практически всегда это результаты оценки уровня зрелости процессов, а также выявленные «узкие места» и связанные с ними риски.
После раздела «Выводы» логичным кажется наличие каких-то рекомендаций, однако, в контексте идущего ITSM-проекта на этом можно сэкономить: проект запущен, бюджет утверж-ден, требования сформулированы – пора приступать к проектированию.
Проектную группу заказчика часто интересует содержание интервью, которые консультанты проводят с высшим руководством ИТ-службы и представителями бизнеса. Чтобы удовлетворить такой интерес, рекомендуется заранее согласовать с руководством публикацию обсуждаемых тем в отчете или присутствие руководителя проектной группы заказчика на интервью.
На основе него разрабатывается промежуточный продукт «План обследования», производным от него является «внешний» продукт «План-график обследования». Продукт «План-график обследования» считается готовым, когда он согласован с заказчиком. В этот момент мы имеем четкое представление, как будет проходить обследование. Следующим за «Планом обследования» «внутренним» продуктом является комплект материалов, составляющих «Результаты обследования» – все, что собрано в рамках обследования. Далее производится «Отчет об обследовании» – основной результат этапа. Производным от него может быть «опциональный» продукт «Презентация итогов обследования».
Цель этапа проектирования – предложить и согласовать с заказчиком организационные и технические решения, которые лягут в основу создаваемой системы управления ИТ. Основные результаты этапа – «Модель системы управления ИТ» и детализирующие ее «Описания (регламенты) процессов».
Процессная модель
Форма
Текстовый документ, презентация (преимущественно).
Назначение
Процессная модель представляет собой набор ключевых характеристик создаваемой системы управления. Это наиболее дорогостоящие элементы дизайна будущей системы, относительно которых требуется принять решения на ранних стадиях проекта, чтобы избежать существенных переработок. Процессная модель компактна, содержит только важное, удобна для обсуждения и согласования.
На основе чего разрабатывается
Исходными ограничениями при разработке процессной модели являются определение проекта в организации и соответствующие положения договора с исполнителем. Как правило, заранее определен состав процессов – подсистем будущей системы управления. Известны и утверждены цели проекта, например, «Внедрение в Департаменте ИТ-процессного подхода, ориентированного на потребности бизнеса. Внедрение элементов мировой «лучшей практики» управления ИТ».
Внешними источниками, используемыми при разработке модели, являются принятые к использованию стандарты, «лучшие практики», а также предыдущий опыт членов команды.
Основной проектный источник разработки – отчет об обследовании, а точнее описание текущей практики и «узкие места» в ней. Новая модель должна сохранить хорошо работающие методы управления и устранить недостатки.
В описании процессной модели имеет смысл опираться на широко используемое деление системы на три составные части – «процессы», «люди», «средства автоматизации».
Для каждого процесса, как правило, модель фиксирует следующие элементы решения:
- Термины и определения;
- Профиль применяемых стандартов и методов управления;
- Целевой уровень зрелости и его характеристики;
- Цели процесса;
- Входы и выходы (результаты) процесса;
- Информационные объекты;
- Виды деятельности, общая схема процесса.
Набор остальных ключевых характеристик (другими словами – «политик»), включенных в модель, является специфическим для каждого процесса. Для управления инцидентами это может быть число линий поддержки, вариант организации службы поддержки (централизованная или распределенная, решающая или регистрирующая), поддерживаемые способы обращения в службу поддержки.
В части ролевой структуры системы («люди») в модели определяется состав и ответственность ролей за виды деятельности процессов. Для каждой роли должна быть оценена возможность назначения или найма персонала. В случае необходимости изменения оргструктуры на это должно быть явно указано.
Что касается средств автоматизации, если они к этому моменту еще не выбраны и не приобретены, то в процессную модель включается перечень планируемых к использованию программных средств и определяется необходимость и методы интеграции со смежными системами (источниками данных о сотрудниках, системами инвентаризации, почтовой программой и т.д.).Чтобы процессная модель не превратилась в маркетинговый материал или, скажем, самоотчет проектной команды (на чем хотелось бы сэкономить), рекомендуется включать в нее те элементы системы, для которых обсуждались альтернативные варианты дизайна.
Модель – центральный продукт этапа. Разработка и согласование модели происходит в несколько итераций с привлечением максимально широкой рабочей группы заказчика. Ошибки, допущенные при разработке модели, обязательно дадут о себе знать на последующих этапах проекта. Цена вопроса: как минимум, существенная переработка уже полученных результатов и неудовлетворенность заказчика. На основе согласованной модели разрабатываются «Схемы процессов» как промежуточный шаг при разработке «Описаний (регламентов) процессов».
Регламент процесса
Форма
Текстовый документ, содержащий графические схемы.
Назначение
Прочитав регламент, участники процесса и заинтересованные лица (например, аудиторы) должны получить представление о следующих вещах: с какой целью и какие действия выполняются в процессе (без подробного описания, как именно) и кто за что отвечает.
На основе чего разрабатывается
Полуфабрикатом для разработки регламента является процессная модель. Согласованные ранее виды деятельности разбиваются на процедуры, определяются участники процедур и ответственные. Описываются сами процедуры, условные и безусловные переходы между ними, более подробно – в точках передачи управления.
Регламент представляет собой логически связанное формальное описание видов деятельности процесса с указанием ответственных. Вот примерная структура регламента (возьмем управление инцидентами):
- Термины и определения;
- Общие положения:
- Цели и задачи процесса;
- Преимущества процесса;
- Область применения и границы процесса;
- Входы в процесс управления инцидентами;
- Выходы из процесса управления инцидентами;
- Общая схема и описание процесса;
- Инструментальные средства процесса;
- Роли и обязанности участников процесса:
- Функциональные роли;
- Матрица ответственности;
- Регламент процесса:
- Прием и регистрация;
- Классификация и первичная поддержка;
- Назначение;
- Разрешение, выполнение;
- Закрытие;
- Владение;
- Метрики процесса:
- Компоненты и отчеты, предоставляемые процессом;
- Приложение А – Правила классификации;
- Приложение Б – Правила определения приоритетов;
- Приложение В – Правила эскалации.
Чтобы регламент мог быть использован по назначению, то есть быть прочитанным до конца, рекомендуется все отвлекающие, нарушающие логически связанное описание подробности вынести в приложения или другие документы (спецификации и инструкции).
Цель этапа разработки – создание средств автоматизации и разработка процессной документации.
На основе «Описаний (регламентов) процессов» разрабатываются «Спецификации процессов». Для каждого процесса управления в составе системы разрабатываются три спецификации: «Спецификация воркфлоу», «Спецификация метрик» и «Спецификация интеграции». На их основе разрабатываются «Сценарии тестирования СА».
Спецификация процесса
Форма
Текстовый документ.
Назначение
Спецификация процесса детализирует положения регламента. Если регламент устанавливает, что и в какой последовательности выполняется в процессе, то спецификация отвечает на вопрос: как именно и с какими результатами выполняются процедуры. Как проектный документ спецификация содержит основные функциональные требования для разработки автоматизированной системы. В дальнейшем используется в качестве основы для составления сценариев тестирования и рабочих инструкций участников процессов.
На основе чего разрабатывается
Спецификация разрабатывается на основе регламента и детализирует его процедуры с учетом ограничений и возможностей выбранных средств автоматизации.
В спецификации процедуры процесса разбиваются на последовательность шагов – элементарных операций участников процесса (пользователей системы). Структура описания процедуры примерно следующая:
- Описание процедуры:
- Номер (идентификатор) процедуры;
- Название процедуры;
- Описание процедуры (из регламента);
- Ответственный исполнитель (роль);
- Вход в процедуру (событие, активирующее процедуру);
- Операции.
Для каждой операции указывается:
- Номер операции;
- Название операции;
- Выполняемые действия;
- Результат операции.
После внедрения системы управления в эксплуатацию для сокращения затрат на сопровождение рекомендуется вносить изменения сначала в регламент и спецификацию, а затем «нарезать» из спецификации инструкции и сценарии.
Параллельно идет работа по созданию средств автоматизации: создается промежуточный продукт «Базовый стенд СА (системы автоматизации)», затем «Рабочий стенд СА» – путем настройки базового стенда согласно спецификациям. «Внешний» продукт «Опытный стенд СА» получается на основе «Рабочего стенда СА» и набора «Сценарии тестирования СА»: усилиями команды тестировщиков и инженеров система автоматизации доводится до готовности к демонстрации заказчику, обучению и опытной эксплуатации.
На основе спецификаций и «Опытного стенда СА» разрабатывается набор продуктов «Инструкции пользователей СА». Результирующим «внешним» продуктом этапа является «Демонстрация СА» проектной команде заказчика.
Опциональными «внешними» продуктами на данном этапе могут быть: «Техническое задание» (на основе спецификаций), «Методика испытаний» (на основе «Сценариев тестирования»), «Описание системы показателей» (на основе набора «Спецификаций метрик»).
Цель этапа развертывания – подготовить объект управления к опытному или опытно-промышленному использованию системы автоматизации.
План опытной (опытно-промышленной) эксплуатации
Форма
Текстовый документ, план в MS Project.
Назначение
Документ служит инструментом планирования и организации совместных действий участников для гарантированного достижения целей опытной эксплуатации в заданный срок (как правило, от двух недель до полутора месяцев).
На основе чего разрабатывается
План включает два крупных раздела: регламент проведения опытной эксплуатации и собственно план.
Регламент проведения опытной эксплуатации отвечает на следующие вопросы:
- Какие цели должны быть достигнуты?
- Каковы сроки проведения опытной эксплуатации?
- Какие подразделения и сотрудники участвуют?
- Какие роли в процессах им назначены?
- Какие методические материалы доступны участникам и где они опубликованы?
- К кому и по каким вопросам обращаться, в какие сроки и каким образом?
- В каком режиме используются «старые» системы и технологии?
- Будут ли вноситься изменения в систему во время опытной эксплуатации?
План опытной эксплуатации включает перечень этапов и задач с указанием ответственных, длительности и сроков по каждому мероприятию. Примерами таких мероприятий могут быть «запуск и апробация приема обращений пользователей с использованием Web-интерфейса», «проведение конфигурационного аудита».
Результаты этого этапа по большей части «внешние» – видимые заказчику. Если следовать привычной структуре «люди», «процессы» и «средства автоматизации», это следующие продукты: «Обученный персонал», «Организационные мероприятия» (для запуска и начала эксплуатации системы управления ИТ) и развернутые на площадке заказчика «Средства автоматизации». Чтобы получить эти результаты, разрабатываются и согласовываются с заказчиком «План обучения», «План развертывания СА», «План выпуска приказов и распоряжений» о начале опытно-промышленной эксплуатации. Параллельно в интересах следующего этапа разрабатывается «внешний» продукт «План опытно-промышленной эксплуатации».
Цель этапа опытно-промышленной эксплуатации – апробировать систему управления ИТ в производственных условиях на площадке заказчика. На основе «Плана опытно-промышленной эксплуатации» в ходе этапа формируется «внутренний» продукт «Результаты опытно-промышленной эксплуатации», на основе которого будут подготовлены «внешние» продукты «Отчет об опытно промышленной эксплуатации» и «Протокол замечаний и доработок». «Опциональным внешним» продуктом этапа может стать «Презентация итогов опытно-промышленной эксплуатации».
Центральное событие этапа ввода в промышленную эксплуатацию – начало использования системы управления ИТ в промышленном режиме. Для этого необходимо устранить замечания, сформулированные на этапе опытно-промышленной эксплуатации. На основе «Опытного стенда СА» и «Протокола замечаний и доработок» разрабатывается «внешний» продукт «Промышленный стенд СА». Результирующим этап и проект в целом является «внешний» продукт «Презентация итогов проекта».
С точки зрения планирования и организации работ техническая поддержка и сопровождение системы управления ИТ имеет скорее процессную, чем проектную природу, и строится по другим правилам. Поэтому на нашей карте продукты проекта, связанные с деятельностью по поддержке и сопровождению, не отражены.
Таким образом, с помощью карты продуктов мы рассмотрели технологию выполнения проекта разработки и внедрения «индивидуального решения» для системы управления ИТ по «классической» схеме. Следует заметить, что для простоты изложения состав продуктов проекта был упрощен. В реальных картах, которые мы используем, для одного продукта проекта может быть предусмотрено несколько промежуточных продуктов. К примеру, «Продукт» становится сначала «Черновиком продукта», затем, после внутренней приемки, «Проектом продукта» и только после согласования с заказчиком – собственно «Продуктом». Другими словами, в карте могут быть отображены не только продукты и их взаимосвязи, но и жизненные циклы отдельных продуктов.
Составив такую карту продуктов, можно перейти к составлению плана проекта, например, с использованием Microsoft Project. Продукты проекта в плане будут представлены в виде вех, которые необходимо детализировать проектными работами. Для этого требуется каждую совокупность входящих связей продукта сформулировать в виде задач по изготовлению продукта на основе предыдущих. Оценив длительность получившихся проектных задач, получим базовый план проекта.
«Классический» способ внедрения наиболее распространен на рынке консалтинговых услуг, имеет широкую популярность и проверен временем. Тем не менее он обладает одним недостатком, вернее особенностью, которая в сегодняшних условиях приобретает все большее значение как для заказчика, так и для исполнителя. Речь идет о длительности. Проекты внедрения систем управления «классическим» способом редко реализуются быстрее, чем за три месяца. Напротив, совсем не редкость, когда такие проекты длятся более года. За это время могут измениться внешние условия, в которых действует компания,
а также планы, приоритеты бизнеса. Трансформируется представление руководителей ИТ-службы о том, как должна работать система управления. Все эти факторы, а также ошибки планирования накапливаются и приводят к тому, что на середине и поздних этапах проекта возрастает желание сократить отставание в ущерб либо качеству, либо количеству продуктов проекта.
«Итерационный» способ внедрения существенно снижает влияние этих рисков. Он нацелен, в первую очередь, на возможность корректировки хода внедрения, предполагая на каждой итерации пересмотр дальнейших планов.
Очевидно, что результат «итерационного проекта» по формальным объектам поставки не должен отличаться от «классического проекта». Приведем общую схему формального комплекта объектов поставки:
Все эти продукты должны быть получены в рамках «итерационного проекта», равно как они получаются в рамках «классического проекта».
Итерация предполагает повторение. В нашем случае повторяться будут следующие группы задач:
Очевидно, что «приемка релиза» как в мини-цикле разработки, так и в цикле основной итерации, приводит либо к переходу к новой итерации, либо к повторению (в некотором объеме) текущей с целью устранения недостатков.
Итак, мы описали, что необходимо получить (продукты проекта) и каким способом мы собираемся это делать (цикл одной итерации). Осталось показать, каким числом итераций будет разработан продукт, и немного детализировать работы внутри каждой итерации. Мы считаем, что оптимальным количеством итераций будет три, четвертая и последующие вполне могут выполняться в рамках технической поддержки и сопровождения системы управления ИТ. Так же, как для «классического» способа разработки, рассмотрим логику получения основных продуктов проекта в разрезе трех итераций проекта.
Группа проектных задач «Исследование» в рамках первой итерации включает большой объем работ, которые при «классической» разработке выполняются на этапах обследования и проектирования:
Задачи, входящие в группу «Разработка», выполняются для получения прототипа системы, готового к демонстрации заказчику.
Завершает первую итерацию разработки группа проектных задач «Приемка», в которую войдут следующие работы:
Таким образом, при заранее оговоренных условиях и ограничениях мы получаем в некотором роде законченное, работающее решение (пилотный релиз), которое включает следующие продукты:
Группа проектных задач «Исследование» в рамках второй итерации имеет существенно меньший масштаб, чем для пилотного релиза, и включает одну задачу:
Группу проектных задач «Определение границ релиза» составляют следующие работы:
Результирующими продуктами итерации 2 являются:
Для получения промышленного релиза группа проектных задач «Исследование» нацелена на расширение круга участников для более глубокой и качественной апробации решения в условиях, максимально приближенных к реальным.
Отчет об опытной (опытно-промышленной) эксплуатации
Форма
Текстовый документ.
Назначение
Документ фиксирует результаты оценки работы участников опытной эксплуатации с точки зрения целей этого этапа проекта, а также демонстрирует текущее состояние системы управления, ее готовность к промышленному использованию и направления совершенствования.
На основе чего разрабатывается
Отчет служит для сравнения плановых показателей с фактическими, поэтому в разработке используются две группы источников информации. В качестве базы для оценки рассматривается план опытной эксплуатации и методические материалы для участников процессов (регламенты, инструкции и т.п.), а фактические данные формируются участниками опытной эксплуатации в процессе работы и анализируются консультантами в ходе аудита системы.
Типовой отчет содержит три раздела: общие сведения, оценка выполнения плана опытной эксплуатации, оценка деятельности в рамках реорганизованных процессов.
Общие сведения – это, в первую очередь, источники данных и критерии оценки, используемые для формирования отчета. Желательно, чтобы выбранные критерии охватывали и управление процессами, и выполнение процедур процессов, и результаты выполнения плана опытной эксплуатации.
Оценка выполнения плана опытной эксплуатации проводится по каждому пункту плана. В случае полного или частичного невыполнения указываются причины. В разделе могут быть приведены некоторые важные количест-венные и качественные характеристики результатов, например, количество ошибок и замечаний.
Оценка деятельности в рамках процессов проводится по разработанным критериям с формированием обобщенной оценки успешности запуска каждого процесса и системы управления в целом. При этом могут быть использованы метрики и средства отчетности, входящие в состав внедряемой системы. Полезной составляющей этого раздела отчета является описание выявленных недостатков, связанных с ними рисков, а также рекомендации по снижению их влияния.
При внедрении сложной, функционально насыщенной системы на большом участке (например, когда эксплуатация не опытная, а опытно-промышленная) полезно через одну-две недели после запуска подготовить краткий промежуточный отчет.
В группу войдут следующие работы:
Группа проектных задач «Разработка» по своему содержанию также повторяет предыдущую итерацию. Завершает итерацию группа проектных задач «Приемка», в которую войдут следующие работы:
Итак, продуктами итерации 3 являются:
Таким образом, итерационный способ внедрения обеспечивает наличие всех ключевых продуктов проекта, создавая дополнительную ценность в виде возможности постоянного пересмотра хода проекта. Особенностью итерационного способа является то, что в результате каждой итерации заказчик имеет целостный набор документов, средств автоматизации и персонала. С таким набором организация имеет возможность продолжить разработку системы управления ИТ с учетом новых обстоятельств и в новых условиях, вплоть до отказа от услуг стороннего поставщика.
В статье мы рассказали о нескольких альтернативных вариантах внедрения автоматизированной системы управления деятельностью ИТ-подразделения. Это «Решение от производителя», «Лучшая практика» и «Индивидуальное решение», которое, в свою очередь, может быть разработано как «классическим», так и «итерационным» способом.
Рассмотренные варианты различаются не только качественными характеристиками. Между базовой настройкой системы автоматизации «из коробки» и внедрением несколько раз апробированного «индивидуального» решения имеется существенная разница в сроках и стоимости проекта для заказчика.
Нет никаких сомнений, что дополнительное время и ресурсы, потраченные организацией на анализ и выбор способа внедрения на этапе подготовки проекта, окупаются более точным «попаданием» итогов проекта в запланированный бюджет и ожидания заинтересованных лиц.
Успешных вам проектов!
РАСПОРЯЖЕНИЕО РАЗРАБОТКЕ, СОГЛАСОВАНИИ И УТВЕРЖДЕНИИ В ОАО "РЖД" ИНСТРУКЦИИ О ПОРЯДКЕ ОБСЛУЖИВАНИЯ И ОРГАНИЗАЦИИ ДВИЖЕНИЯ НА ЖЕЛЕЗНОДОРОЖНОМ ПУТИ НЕОБЩЕГО ПОЛЬЗОВАНИЯ, А ТАКЖЕ ЖЕЛЕЗНОДОРОЖНОМ ПУТИ, НАХОДЯЩЕМСЯ В ВЕДЕНИИ ФУНКЦИОНАЛЬНОГО ФИЛИАЛА ИЛИ СТРУКТУРНОГО ПОДРАЗДЕЛЕНИЯ ОАО "РЖД"
В целях усовершенствования единого порядка по разработке, согласованию и утверждению инструкции о порядке обслуживания и организации движения на железнодорожном пути необщего пользования, железнодорожном пути, находящемся в ведении функционального филиала или структурного подразделения ОАО "РЖД" и не являющемся железнодорожным путем необщего пользования:
1. Утвердить и ввести в действие прилагаемые:
1.1. Порядок разработки, согласования и утверждения в ОАО "РЖД" инструкции о порядке обслуживания и организации движения на железнодорожном пути необщего пользования, а также железнодорожном пути, находящемся в ведении функционального филиала или структурного подразделения ОАО "РЖД" (далее - Порядок).
1.2. Инструкцию о порядке обслуживания и организации движения на железнодорожном пути необщего пользования, принадлежащем ОАО "РЖД", а также железнодорожном пути, находящемся в ведении функционального филиала или структурного подразделения ОАО "РЖД" (далее - Инструкция).
2. Руководителям функциональных филиалов и структурных подразделений ОАО "РЖД" довести Порядок и Инструкцию до сведения причастных работников, владельцев и пользователей железнодорожных путей необщего пользования, железнодорожных путей, находящихся в ведении функциональных филиалов или структурных подразделений ОАО "РЖД", обеспечить соблюдение установленного Порядка.
3. Признать утратившим силу распоряжение ОАО "РЖД" от 2 августа 2011 г. N 1686р "О разработке, согласовании и утверждении в ОАО "РЖД" инструкции о порядке обслуживания и организации движения на железнодорожном пути необщего пользования".
4. Контроль за выполнением настоящего распоряжения возложить на вице-президента - начальника дирекции тяги Воротилкина А.В., начальника Центральной дирекции управления движением Иванова П.А., начальника Центральной дирекции инфраструктуры Супруна В.Н., начальника Центральной дирекции моторвагонного подвижного состава Сизова С.В., начальника Центральной дирекции по ремонту пути Пименова И.Я., начальника Дирекции по ремонту тягового подвижного состава Акулова А.П. в соответствии с функциональной компетенцией вопросов.
Старший вице-президент ОАО "РЖД"
А.А.Краснощек
отменен/утратил силу Редакция от 18.02.1991
"УСТАВ АВТОМОБИЛЬНОГО ТРАНСПОРТА РСФСР" (ред. от 18.02.91)
Автомобильные дороги и подъездные пути
16. Автомобильные дороги общего пользования, находящиеся на территории РСФСР, подразделяются на дороги общегосударственного, республиканского и местного значения. Из дорог местного значения выделяются дороги областного значения.
Автомобильные дороги общегосударственного и республиканского значения находятся в ведении Министерства строительства и эксплуатации автомобильных дорог РСФСР.
Автомобильные дороги республиканского значения передаются Министерством автомобильного транспорта и шоссейных дорог РСФСР для постоянного обслуживания дорожным органам соответствующих Советов Министров автономных республик и исполнительных комитетов областных (краевых) Советов народных депутатов.
Автомобильные дороги местного значения находятся в ведении Министерства автомобильного транспорта и шоссейных дорог РСФСР и Советов Министров автономных республик, исполнительных комитетов областных (краевых) Советов народных депутатов.
Автомобильные дороги в пределах городов и рабочих поселков находятся в ведении соответствующих исполнительных комитетов Советов народных депутатов.
от 28.11.69 N 648 , от 16.05.80 N 253)
17. Министерство автомобильных дорог РСФСР, Советы Министров автономных республик, исполнительные комитеты Советов народных депутатов, а также колхозы, совхозы и другие предприятия и организации обязаны содержать находящиеся в их ведении автомобильные дороги, дорожные знаки, указатели и другие технические средства регулирования движения в состоянии, обеспечивающем беспрепятственное и безопасное движение автомобилей, а также принимать необходимые меры к улучшению движения на этих дорогах.
(в ред. Постановлений Совмина РСФСР от 28.11.69 N 648 , от 16.05.80 N 253)
18. Автотранспортные предприятия и организации, а также другие предприятия, организации и учреждения, имеющие автомобили, при перевозке грузов, пассажиров, багажа и почты по автомобильным дорогам обязаны обеспечивать безопасность движения и сохранность дороги.
На автомобильных дорогах запрещается:
а) проезд транспортных средств, общая высота которых с грузом превышает указанные на дорожных знаках габариты;
б) провоз грузов, выступающих по ширине за габариты транспортных средств, установленные государственным стандартом или техническими условиями, а также грузов, выступающих за задний борт более чем на 2 метра или волочащихся по дороге;
в) проезд всех видов транспортных средств с нагрузками на ось, превышающими нормы, установленные государственными стандартами или указанные на дорожных знаках.
Перевозка негабаритных грузов может осуществляться в отдельных случаях по разрешению дорожных органов и органов Государственной автомобильной инспекции в порядке, предусмотренном Правилами.
19. Министерство автомобильного транспорта РСФСР и Министерство автомобильных дорог РСФСР оказывает на автомобильных дорогах техническую помощь подвижному составу, независимо от его принадлежности, с оплатой стоимости оказанных услуг по тарифам.
На автомобильных дорогах общегосударственного значения техническая помощь подвижному составу в пути организуется средствами дорожно-эксплуатационных организаций Министерства автомобильных дорог РСФСР. На этих же дорогах техническую помощь подвижному составу оказывают станции технического обслуживания автомобилей и автотранспортные предприятия Министерства автомобильного транспорта РСФСР по месту их нахождения.
Перечень автомобильных дорог, на которых организуется техническая помощь, утверждается Министерством автомобильного транспорта РСФСР совместно с Министерством автомобильных дорог РСФСР и публикуется в Сборнике правил перевозок и тарифов автомобильного транспорта РСФСР.
Порядок организации на автомобильных дорогах технической помощи подвижному составу определяется Положением об организации технической помощи подвижному составу на автомобильных дорогах в РСФСР, утверждаемым Министерством автомобильного транспорта РСФСР совместно с Министерством автомобильных дорог РСФСР.
(в ред. Постановлений Совмина РСФСР от 28.11.69 N 648 , от 16.05.80 N 253)
20. Временное прекращение или ограничение перевозок грузов, пассажиров, багажа и почты по автомобильным дорогам в РСФСР может производиться только в случаях явлений стихийного характера или из-за дорожно-климатических условий.
Решения о прекращении или ограничении перевозок грузов, пассажиров, багажа и почты с указанием срока действия прекращения или ограничения перевозок по автомобильным дорогам общегосударственного значения принимаются Министерством строительства и эксплуатации автомобильных дорог РСФСР, по остальным дорогам общего пользования - Советами Министров автономных республик или исполнительными комитетами областных (краевых) Советов народных депутатов.
О временном прекращении или ограничении перевозок по автомобильным дорогам общегосударственного значения Министерство автомобильных дорог РСФСР, а по остальным дорогам Советы Министров автономных республик и исполнительные комитеты областных (краевых) Советов депутатов трудящихся обязаны доводить до сведения заинтересованных предприятий, организаций, учреждений и граждан.
В неотложных случаях органы Государственной автомобильной инспекции могут запрещать или ограничивать движение автомобилей, осуществляющих перевозки, по отдельным участкам улиц и дорог, когда пользование ими угрожает безопасности движения.
(в ред. Постановлений Совмина РСФСР от 28.11.69 N 648 , от 16.05.80 N 253)
21. Грузоотправители и грузополучатели обязаны иметь подъездные пути от автомобильных дорог к пунктам погрузки и выгрузки и содержать эти пути в исправном состоянии, обеспечивающем беспрепятственное и безопасное движение автомобилей и свободное маневрирование их в любое время осуществления перевозок.
22. Соответствие состояния автомобильных дорог и подъездных путей, находящихся на территории РСФСР, требованиям безопасности движения и сохранности груза и подвижного состава определяется совместно соответствующими дорожными органами, автотранспортными предприятиями или организациями и органами Государственной автомобильной инспекции.
Доставка грузов автомобильным транспортом чаще всего производится “от двери до двери”, то есть, перевозчик забирает груз непосредственно у грузоотправителя и выдает его получателю. В этом несомненное преимущество автомобильного транспорта перед другими его видами — железнодорожным, водным и воздушным. Всё что нужно для выполнения автоперевозки — пригодная для движения грузового транспорта дорога. И если дороги общего пользования чаще всего дают возможность по ним проехать (хотя в России возможны варианты), то подъездные пути к местам погрузки, разгрузки и погрузочно-разгрузочные площадки не всегда пригодны для движения грузового транспорта.
Часто такая проблема происходит на стройплощадках и с ней сталкиваются водители, перевозящие сыпучие строительные материалы — щебень, гравий, песок и т. д. Территория захламлена, на дорогу нет и намека, из земли торчат железные прутья, а прораб энергично требует заезжать. Знакомая ситуация? Давайте в ней разберемся.
Для начала надо понять что такое “подъездной путь”. Законодательство не дает определение понятию “автомобильный подъездной путь”, поэтому следует руководствоваться буквальным его толкованием — это путь, соединяющий строительную площадку и объекты государственной и частной собственности с общегосударственной и частной сетью автомобильных дорог.
Законодательство, регулирующее отношения сторон договора перевозки, не содержит прямых указаний относительно действий водителя в случае, если подъехать к месту погрузки или выгрузки невозможно из-за отсутствия подъездного пути. УАТиГНЭТ* и ППГАТ** также не содержат никаких упоминаний об этой довольно часто встречающейся ситуации.
До конца марта 2018 года на территории РФ действовали Общие правила перевозок грузов автомобильным транспортом (утверждены Минавтотрансом РСФСР 30.07.1971 года). § 5 раздела 5 “Правила погрузки и разгрузки грузов” гласят буквально следующее: “Грузоотправитель и грузополучатель обязаны содержать погрузочно-разгрузочные площадки, а также подъездные пути к ним в исправном состоянии в любое время года для обеспечения беспрепятственного проезда и маневрирования подвижного состава, а также обеспечить надлежащее освещение для работы в вечернее и ночное время”. Приказом Минтранса РФ от 23.03.2018 года № 113 ОППГАТ были признаны утратившими силу.
В любом случае, обязанность грузоотправителя и грузополучателя содержать подъездные пути и и погрузочно-разгрузочные площадки в надлежащем состоянии не вступает в противоречие с другими нормами права. Более того, это требование согласуется с презумпцией добросовестности сторон гражданских правоотношений (ст. 10 ГК РФ).
С другой стороны, законодательно действия сторон при возникновении такой ситуации четко не определены, поэтому рекомендуется предусмотреть в договоре порядок уведомлений и действий перевозчика в случае, если подъехать к месту погрузки или выгрузки невозможно либо слишком затруднительно. Такое условие дисциплинирует грузоотправителей и грузополучателей, а в случае, если подъезд или маневрирование на выгрузке невозможен — избежать трудностей в фиксации и удостоверении этого факта.
