=?UTF-8?B?0J RgNC40LvQvtC20LXQvdC40LUgMi4=?= =?UTF-8?B?INCf0YDQvtC10LrRgiDQtNC+0LPQvtCy?= =?UTF-8?B?0L7RgNCwX9Cg0LDQt9Cy0LjRgtC40LVfMl QutCy0LDRgNGC0LDQuy5wZGY=?=

Приложение 2
Проект договора
Договор на оказание услуг
№ ________________
г. Москва
“___” __________ 201_г.
_____________________________ «________________________________», в лице _________, действующего на
основании ___________, именуемое в дальнейшем «Исполнитель», с одной стороны, и Открытое акционерное
общество междугородной и международной электрической связи «Ростелеком», именуемое в дальнейшем
«Заказчик», в лице Вице-Президента - Директора по информационным технологиям Садкова Д.В,, действующего на
основании доверенности 12-642 от 30.09.2013, с другой стороны, заключили настоящий рамочный договор № _______
на оказание услуг (далее – «Договор») о нижеследующем.
1. ПРЕДМЕТ ДОГОВОРА
1.1.
В рамках настоящего Договора в соответствии с Приложением № 1 к Договору (Технические требования),
Исполнитель обязуется оказать Заказчику перечисленные в Приложении № 4 услуги по доработке и развитию системы
Oracle E-Business Suite R12 в ОАО «Ростелеком» (именуется далее Услуги), а Заказчик обязуется принять и оплатить
оказанные Услуги. Расширение перечня услуг, указанных в приложении № 4 не допускается.
1.2.
Услуги оказываются на основании подписанного Сторонами Заказа на Услуги (форма содержится в
Приложении № 2 к Договору), оформляемом в следующем порядке:
1.2.1. Заказчик направляет проект Заказа по факсу (_______________) или электронной почте (_______________)
уполномоченным представителям Исполнителя.
Срок рассмотрения Заказа Исполнителем – один рабочий день с момента получения Заказа. По окончании указанного
срока Исполнитель предоставляет Заказчику оформленный Заказ, подписанный со своей стороны в двух экземплярах
либо мотивированный отказ от его подписания, с указанием на пункты Договора, которому он не соответствует.
Заказчик и Исполнитель в последнем случае дорабатывают текст Заказа в рабочем порядке в срок не более 2 (двух)
рабочих дней.
1.2.2. По завершении согласования проекта Заказа Исполнитель подписывает и скрепляет печатью 2 (два) экземпляра
соответствующего Заказа и направляет их Заказчику. В течение 5 (пяти) рабочих дней с даты получения
соответствующего Заказа Заказчик обязуется подписать и скрепить печатью Заказ со своей Стороны, направить
Исполнителю один экземпляр Заказа.
1.2.3. В проекте Заказа Заказчик указывает сведения, определённые в соответствии с настоящим Договором, а также
иные данные, по усмотрению Заказчика.
1.2.4. Заказ вступает в силу и считается согласованным после его подписания Сторонами.
1.3.
Согласованные Сторонами Заказы являются неотъемлемой частью настоящего Договора.
1.4.
Контактная информация и ответственные лица Заказчика:
__________________________________ (Ф.И.О)
__________________________________ (Должность)
__________________________________ (Контактные данные: телефон, электронная почта)
1.5.
Контактная информация и ответственные лица Исполнителя:
__________________________________ (Ф.И.О)
__________________________________ (Должность)
__________________________________ (Контактные данные: телефон, электронная почта).
1.6.
Срок оказания Услуг по каждому отдельному Заказу, указывается в Заказе.
1.7. Распределение трудозатрат в рамках настоящего Договора в разрезе специалистов составляет:
Менеджер проекта – не более 220 человеко-дней;
Архитектор проекта – не более 240 человеко-дней;
Функциональный консультант – не более 2800 человеко-дней;
Технический консультант–разработчик (далее Технический консультант) – не более 2800 человеко-дней;
1.7.1. По настоящему Договору у Заказчика не возникает обязанности заказать Услуги в объеме, соответствующем
трудоемкости Услуг, указанной в п. 1.7. настоящего Договора.
1.8. Для оказания услуг по Договору Исполнитель будет привлекать необходимое количество специалистов. При этом
гарантирует в случае необходимости единовременно привлечь к оказанию Услуг по Договору как минимум следующее
количество специалистов
Менеджер проекта – не менее 5 человек, в том числе по направлению Финансы – 1 человек, по направлению
Логистика – 1 человек, по КБД – 1 человек, управление проектом внедрения R12 – 2 человека;
Архитектор проекта
– не менее 4 человек, в том числе по направлению Финансы - 1 человек, по направлению
Логистика – 1 человек, архитектор проекта R12 – 2 человека;
Функциональный консультант – не менее 27 человек;
Технический консультант – не менее 19 человек.
1.9. Услуги должны полностью соответствовать Заказу.
2.
ПРАВА И ОБЯЗАННОСТИ СТОРОН
2.1. Исполнитель обязан:
2.1.1. Оказать Заказчику Услуги согласно п.1.1. настоящего Договора.
2.1.2. Оказать Услуги в установленные п.1.6. Договора сроки.
2.1.3. В случае невозможности оказания Услуг, либо изменения условий их оказания, письменно информировать об
этом Заказчика не менее чем за 10 (десять) дней до даты начала оказания Услуг, указанной в соответствующем Заказе.
2.1.4. По окончании оказания Услуг по соответствующему Заказу, Исполнитель выставляет Заказчику счет на оплату
оказанных Услуг и Акт сдачи-приемки Услуг (далее Акт). Стороны могут согласовать иные условия приемки Услуг и
условия оплаты Услуг в Заказе.
2.1.5. Вместе с Актом Исполнитель направляет Заказчику оригинал счета-фактуры, оформленного в соответствии с
законодательством Российской Федерации.
2.2. Заказчик обязан:
2.2.1. Своевременно, в порядке, предусмотренном Договором, принять и оплатить Услуги.
2.2.2. Своевременно предоставлять Исполнителю информацию, необходимую для оказания Услуг по настоящему
Договору, в том числе информацию по Проекту в срок не более 5 рабочих дней с момента получения запроса от
Исполнителя. Несоблюдение Заказчиком указанных в настоящем пункте условий может повлечь за собой изменение
сроков оказания Услуг по Заказу.
2.2.3. Заказчик обязуется обеспечить доступ специалистов Исполнителя к ресурсам используемых прикладных
систем и инфраструктурным элементам, необходимым для оказания Услуг и указанным в Технических требованиях
(Приложение № 1 к Договору).
2.2.4. В случае, если Услуги оказываются на территории Заказчика, последний должен обеспечить
беспрепятственный доступ специалистов Исполнителя в помещения, где оказываются Услуги, предоставить
специалистам Исполнителя условия для оказания Услуг в согласованном Сторонами объеме, в том числе рабочие места
с телефонами и доступом в Интернет, доступ к программному обеспечению, как это будет указано в соответствующем
Заказе.
2.2.5. В случае оказания Услуг на территории Исполнителя Заказчик обеспечивает удаленный доступ к системе
Oracle e-Business Suite для специалистов Исполнителя, как это будет указано в соответствующем Заказе.
2.3. Исполнитель имеет право:
2.3.1. Исполнитель вправе отказаться от исполнения обязательств по Договору с последующим полным возмещением
Заказчику убытков.
2.4. Заказчик имеет право:
2.4.1. Заказчик вправе в любое время отказаться от Договора, направив письменное уведомление об этом Исполнителю.
В случае прекращения Договора Исполнитель возвращает Заказчику все суммы, полученные им по Договору, а
Заказчик оплачивает документально подтвержденные фактически понесенные Исполнителем расходы, направленные на
исполнение обязательств по Договору.2.4.2. В случае, если Заказчик не удовлетворен Услугами, оказываемыми
специалистами Исполнителя, Заказчик вправе обратиться к Исполнителю с мотивированным требованием о замене
данного специалиста.
3.
ОПЛАТА УСЛУГ
3.1.
Предельная стоимость Услуг, в течение срока действия Договора, не может превышать ______________ (____)
российских рублей __ копеек, в том числе НДС (18%) в размере _____________(____________) российских рублей __
копеек. По настоящему Договору у Заказчика не возникает обязанности заказать Услуги на всю указанную сумму.
3.2.
Стоимость Услуг указывается в соответствующих Заказах и рассчитывается, исходя из приведенных ниже
ставок специалистов Исполнителя за рабочий день (8-ми часовой рабочий день с понедельника по пятницу, за
исключением официальных праздничных дней), срока оказания Услуг по Заказу, количества человеко-дней
необходимых для оказания Услуг по Заказу:
Дневная ставка Менеджера проекта –__________ руб в день, с НДС;
Дневная ставка Архитектора проекта
–__________ руб в день, с НДС;
Дневная ставка Функционального консультанта –__________ руб в день, с НДС;
Дневная ставка Технического консультанта –__________ руб в день, с НДС.
Увеличение ставок специалистов в течение срока действия договора не допускается.
3.3.
Указанная в согласованном Сторонами Заказе цена Услуг включает в себя все платежи, причитающиеся
Исполнителю
за
выполнение
обязательств
по
соответствующему
Заказу.
3.4. Услуги оплачиваются в следующем порядке:
В течение 90 (Девяноста) календарных дней с момента получения Заказчиком выставленного Исполнителем оригинала
счета Заказчик осуществляет оплату в размере 100% общей стоимости оказываемых Услуг по соответствующему
Заказу. Исполнитель выставляет счет в течение 5 (пяти) рабочих дней с момента подписания Сторонами Акта сдачиприемки Услуг по соответствующему Заказу в порядке, предусмотренном статьей 4 Договора.
3.5.
Расчеты по Договору производятся в безналичной форме в рублях РФ.
3.6.
Обязательства Заказчика по оплате Услуг считаются исполненными с момента списания денежных средств с
расчетного счета Заказчика.
3.7.
По мере необходимости Стороны осуществляют сверку расчётов по Договору с оформлением двустороннего
акта сверки расчётов. Акт сверки расчётов составляется заинтересованной Стороной в двух экземплярах, каждый из
которых должен быть подписан уполномоченным представителем этой Стороны и скреплён её печатью. Сторонаинициатор направляет в адрес Стороны-получателя два оригинала акта сверки расчётов почтовой связью заказным или
ценным письмом с уведомлением о вручении, курьерской службой или иным согласованным Сторонами способом. В
течение 10 (десяти) рабочих дней со дня получения акта сверки расчётов Сторона-получатель должна подписать,
заверить печатью, направить один экземпляр акта сверки расчётов в адрес Стороны-инициатора, или направить
Стороне-инициатору свои письменные мотивированные возражения по поводу достоверности содержащейся в акте
сверки расчётов информации. Если в течение 10 (десяти) рабочих дней со дня получения акта сверки расчётов Сторонаполучатель не направит в адрес Стороны-инициатора подписанный акт сверки расчётов или письменные
мотивированные возражения по поводу достоверности содержащейся в нем информации, акт сверки расчётов считается
признанным Стороной-получателем в редакции Стороны-инициатора.
3.8.
В течение 5 (пяти) рабочих дней со дня заключения настоящего Договора Исполнитель обязан направить
Заказчику:
- образцы подписей лиц, которые будут подписывать выставляемые в адрес Заказчика счета-фактуры;
- документы, подтверждающие полномочия лиц, которые будут подписывать счета-фактуры (заверенные надлежащим
образом приказы, распоряжения, доверенности, копии банковских карточек или иные аналогичные документы) в
случае, если право их подписи предоставлено иным лицам, кроме руководителя организации и главного бухгалтера.
Исполнитель обязуется в письменной форме информировать Заказчика (с приложением подтверждающих документов)
обо всех изменениях в перечне лиц, имеющих право подписи счетов-фактур, в течение 10 (десяти) рабочих дней со дня
таких изменений.
3.9.
Счета-фактуры выставляются Исполнителем в соответствии с законодательством Российской Федерации.
4.
ПОРЯДОК СДАЧИ И ПРИЕМКИ УСЛУГ
4.1. Сдача-приемка оказанных Услуг осуществляется уполномоченными представителями Сторон путем подписания
Акта по каждому Заказу.
4.2. Заказчик в течение 5 (пяти) рабочих дней со дня получения Акта подписывает Акт, либо направляет
мотивированный отказ от его подписания.
4.3. В случае направления Заказчиком Исполнителю письменного мотивированного отказа от подписания Акта,
Исполнитель устраняет все недостатки, выявленные в Услугах за свой счет в согласованный Сторонами срок. Стороны
вправе договориться также о соразмерном уменьшении стоимости Услуг в случае если обнаруженные недостатки не
могут быть исправлены Исполнителем.
4.4. Услуги по соответствующему Заказу считаются оказанными Исполнителем с момента подписания Сторонами
Акта по соответствующему Заказу.
4.5. Если в ходе оказания Услуг по настоящему Договору будут созданы результаты интеллектуальной деятельности,
Исполнитель передает (отчуждает) Заказчику исключительные права на такие результаты интеллектуальной деятельности в
полном объеме. Стоимость отчуждаемых исключительных прав по настоящему Договору входит в общую стоимость оказания
Услуг. Исключительные права на результаты интеллектуальной деятельности, созданные в ходе оказания Услуг, переходят к
Заказчику незамедлительно с момента подписания Сторонами Акта сдачи-приёмки услуг.
4.6. Исполнитель гарантирует, что им получено согласие от производителя (правообладателя) программного
обеспечения на установку обновлений программного обеспечения и передачу Заказчику прав на использование
обновлений программного обеспечения на условиях простой (неисключительной) лицензии способами, указанными в
ст. 1280 Гражданского кодекса Российской Федерации, если в ходе оказания Услуг такая установка производилась
Исполнителем. Также Исполнитель подтверждает соблюдение законодательства, регулирующего права на результаты
интеллектуальной деятельности и средства индивидуализации об охране авторских и иных прав на объекты
интеллектуальной собственности, действующих на территории Российской Федерации, при исполнении обязательств по
настоящему Договору.
4.7. Сведения о результатах интеллектуальной деятельности, права на которые передаются (отчуждаются) по
настоящему Договору, подлежат отражению в Актах сдачи-приёмки услуг.
5.
КОНФИДЕНЦИАЛЬНОСТЬ
5.1.
Раскрывающая Сторона – Сторона, которая раскрывает конфиденциальную информацию другой Стороне.
5.2.
Получающая Сторона – Сторона, которая получает конфиденциальную информацию от другой Стороны.
5.3.
Настоящим Стороны договорились, что конфиденциальной информацией являются условия настоящего
Договора и любая информация, которой Стороны обменивались в процессе заключения, исполнения и прекращения
Договора. В течение срока действия настоящего Договора и в течение 3 (трех) лет после его прекращения (если
больший срок не предусмотрен законодательством Российской Федерации) Получающая Сторона обязуется не
раскрывать без предварительного обязательно письменного согласия Раскрывающей Стороны любую
конфиденциальную информацию, полученную от Раскрывающей Стороны. Когда любая конфиденциальная
информация раскрывается третьему лицу с таким согласием, Получающая Сторона, раскрывающая такую
конфиденциальную информацию третьему лицу, должна гарантировать, что третье лицо взяло на себя обязательства по
сохранению конфиденциальности такой информации на условиях, аналогичных изложенным в настоящем разделе
Договора.
5.4.
Получающая Сторона, которая получила любую конфиденциальную информацию, в том числе в устной форме
при условии, что письменное сообщение относительно конфиденциальности такой информации было получено от
Раскрывающей Стороны, не должна раскрывать ее, и обязуется обрабатывать такую информацию с той степенью
заботливости и осмотрительности, которая применяется относительно ее информации того же уровня важности.
5.5.
Информация, полученная Получающей Стороной, не рассматривается как конфиденциальная и,
соответственно, у Получающей Стороны не возникает обязательств по сохранению конфиденциальности в отношении
такой информации, если она удовлетворяет одной из следующих характеристик:
5.5.1. информация во время ее раскрытия является публично известной;
5.5.2. информация представлена Получающей Стороне с письменным указанием на то, что она не является
конфиденциальной;
5.5.3. информация получена от любого третьего лица на законных основаниях;
5.5.4. информация не может являться конфиденциальной в соответствии с законодательством Российской Федерации.
5.6.
Получающая Сторона имеет право раскрывать конфиденциальную информацию без согласия Раскрывающей
Стороны:
5.6.1. профессиональным советникам (юристам, аудиторам) при условии, что такие лица взяли на себя обязательства
по сохранению конфиденциальности указанной информации на условиях, аналогичных изложенным в настоящем
разделе Договора, либо обязаны сохранять такую информацию в тайне в соответствии с законодательством Российской
Федерации;
5.6.2. если информация должна быть раскрыта в соответствии с законом, иным нормативно – правовым актом,
судебным актом при условии, что Сторона, которая получила информацию от другой Стороны, предварительно
письменно и с подтверждением необходимости в таком раскрытии уведомит об этом другую Сторону.
5.7.
В случае нарушения условий конфиденциальности одной из Сторон такая Сторона должна возместить второй
Стороне реальный ущерб на основании вступившего в силу решению арбитражного суда.
6.
ОСНОВАНИЯ ИЗМЕНЕНИЯ И РАСТОРЖЕНИЯ ДОГОВОРА
6.1.
Условия, на которых заключен настоящий Договор, могут быть изменены по соглашению Сторон в
соответствии с действующим законодательством Российской Федерации.
6.2. Настоящий Договор может быть расторгнут по соглашению Сторон.
6.3.
При досрочном расторжении Договора Сторонами оформляется двусторонний Акт, подтверждающий оказание
части Услуг, на основании которого Стороны производят взаиморасчеты.
7.
ОТВЕТСТВЕННОСТЬ СТОРОН
7.1.
За неисполнение или ненадлежащее исполнение своих обязательств по настоящему Договору Стороны несут
ответственность в соответствии с действующим законодательством Российской Федерации.
7.2.
За нарушение сроков оказания Услуг/сроков устранения недостатков по соответствующему Заказу Заказчик
вправе потребовать уплаты Исполнителем неустойки в размере 0,1% (ноль целых одна десятая процента) от стоимости
Услуг по соответствующему Заказу за каждый день просрочки.
7.3.
За нарушение сроков оплаты Услуги по соответствующему Заказу Исполнитель вправе потребовать выплаты
неустойки в размере 1/365 (одна триста шестьдесят пятая) от стоимости Услуг по соответствующему Заказу за каждый
день просрочки до дня надлежащего оказания Услуг.
7.4.
При нарушении условий раздела 5 Договора (Конфиденциальность) Сторона, допустившая нарушение,
возмещает другой Стороне все документально подтвержденные причиненные этим убытки в полном объеме.
7.5.
Выплата неустойки по настоящему Договору осуществляется только на основании письменной претензии.
Если письменная претензия одной Стороны не будет направлена в адрес другой Стороны, неустойка не начисляется и
не уплачивается.
7.6.
Стороны уплачивают неустойку, предусмотренную Договором, в течение 10 (десяти) рабочих дней со дня
получения соответствующего требования в письменной форме. Уплата неустойки не освобождает Сторону,
нарушившую Договор, от исполнения своих обязательств в натуре.
8.
ПОРЯДОК РАССМОТРЕНИЯ СПОРОВ
8.1.
Отношения, возникающие на основании настоящего Договора, регулируются законодательством Российской
Федерации.
8.2.
Все споры и разногласия по настоящему Договору Стороны разрешают путём переговоров.
8.3.
Если по итогам переговоров Стороны не достигнут согласия, споры передаются на рассмотрение Арбитражного
суда г. Москвы.
9.
ОБСТОЯТЕЛЬСТВА НЕПРЕОДОЛИМОЙ СИЛЫ
9.1.
Стороны освобождаются от ответственности за частичное или полное неисполнение обязательств по
настоящему Договору, если это неисполнение явилось следствием обстоятельств непреодолимой силы, то есть
чрезвычайных обстоятельств, возникших после заключения настоящего Договора, которые Сторона не могла ни
предвидеть, ни предотвратить разумными мерами. К обстоятельствам непреодолимой силы, например, относятся:
пожар, наводнения, землетрясения, иные стихийные бедствия. Наличие обстоятельств непреодолимой силы
подтверждается соответствующим документом. Акты органов исполнительной власти и местного самоуправления,
равно как и изменения в законодательстве, не должны рассматриваться как обстоятельства непреодолимой силы для
целей исполнения обязательств, предусмотренных Договором.
9.2.
При наступлении обстоятельств непреодолимой силы подвергшаяся их воздействию Сторона должна при
первой возможности незамедлительно в письменной форме известить о данных обстоятельствах другую Сторону.
Извещение должно содержать сведения о характере обстоятельств непреодолимой силы, а также оценку их влияния на
возможность исполнения Стороной своих обязательств по настоящему Договору и предполагаемый срок исполнения
таких обязательств. Срок исполнения Сторонами своих обязательств по настоящему Договору продлевается соразмерно
времени, в течение которого действуют обстоятельства непреодолимой силы и их последствия, препятствующие
исполнению настоящего Договора.
9.3.
По окончании действия обстоятельств непреодолимой силы соответствующая Сторона должна без
промедления, но не позднее 3 (трёх) рабочих дней со дня прекращения обстоятельств непреодолимой силы и их
последствий, препятствующих исполнению настоящего Договора, известить об этом другую Сторону в письменной
форме. В извещении должен быть указан срок, в который предполагается исполнить обязательства по настоящему
Договору.
9.4.
В случаях, когда обстоятельства непреодолимой силы и (или) их последствия продолжают действовать более 3
(трёх) месяцев подряд, любая из Сторон вправе в одностороннем внесудебном порядке расторгнуть настоящий Договор,
предупредив об этом в письменной форме другую Сторону за 10 (десять) рабочих дней до планируемой даты
расторжения Договора. Стороны предпримут все разумные усилия по снижению любых убытков, которые они могут
понести в результате расторжения Договора в связи с действием обстоятельств непреодолимой силы.
10.
ПРОЧИЕ УСЛОВИЯ
10.1.
Настоящий Договор считается заключённым и вступает в силу с момента его подписания обеими Сторонами и
действует в течение 60 (шестидесяти) рабочих дней, либо до исчерпания Стоимости Услуг, указанной в п. 3.1.
Договора, в зависимости от того какое условие наступит раньше. Окончание действия Договора не влечет прекращение
обязательств Сторон, не исполненных в течение срока действия Договора.
10.2.
Гарантийный период на результаты оказанных Услуг составляет 1 (один) год с даты подписания Сторонами
Акта сдачи-приемки Услуг по соответствующему Заказу. Исполнитель обязуется устранять любые недостатки в
оказанных Услугах, выявленные в течение гарантийного периода и возникшие по вине Исполнителя.
10.3. Стороны не имеют права уступить либо передать свои права или обязанности по настоящему Договору,
полностью либо частично, без предварительного письменного согласия другой Стороны.
10.4. Каждая из Сторон вправе передавать свои права и обязанности по настоящему Договору только после получения
письменного согласия другой Стороны.
10.5.
Любые изменения и дополнения к Договору оформляются дополнительными соглашениями, являющимися его
неотъемлемой частью, и действительны лишь при условии, что они совершены в письменной форме и подписаны
обеими Сторонами.
10.6. В случае изменений в цепочке собственников Исполнителя, включая бенефициаров (в том числе конечных), не
позднее 5-ти рабочих дней после таких изменений Исполнитель обязуется предоставлять информацию о таких
изменениях по форме, приведенной в Приложении № 3 к Договору, а также документы, подтверждающие такие
изменения. В случае не предоставления Исполнителем указанной информации и документов в срок, предусмотренный
настоящим пунктом, Заказчик вправе расторгнуть Договор путем одностороннего внесудебного отказа от исполнения
обязательств. Заказчик вправе в одностороннем порядке изменить форму предоставления информации, приведенную в
Приложении № 3 к настоящему Договору, предварительно уведомив об этом Исполнителя.
10.7.
Настоящий Договор составлен в двух экземплярах, имеющих одинаковую юридическую силу, по одному для
каждой из Сторон.
10.8.
Неотъемлемой частью Договора являются:
Приложение № 1 Технические требования;
Приложение № 2 Форма заказа на Услуги;
Приложение № 3 Форма предоставления информации об изменениях в цепочке собственников контрагента, включая
бенефициаров (в том числе, конечных).
Приложение № 4 Перечень услуг
11. Банковские реквизиты и адреса Cторон:
Заказчик:
ОАО «Ростелеком»
Местонахождение:
191002, г. Санкт-Петербург,
ул. Достоевского, д. 15
Почтовый адрес: 125047, Москва,
ул. 1-я Тверская-Ямская, д.14
Тел. (499) 972-80-22, 972-82-83
Факс (499) 972-82-22
Расчётный счёт в рублях РФ 40702810900320000135
в Нижегородском филиале ОАО АКБ «Связь-Банк»
К/с 30101810900000000700
БИК 042202700
ИНН 7707049388 / КПП 771032001
Исполнитель:
Заказчик:
Исполнитель:
Вице-Президент - Директор по информационным технологиям
ОАО «Ростелеком»
___________________ Садков Д.В.
Приложение № 1 к Договору
от «__» _____________
Технические требования
1
Услуги по доработке и развитию системы Oracle E-Business Suite R12 в ОАО «Ростелеком»
1.1 Сведения о системе Oracle E-Business Suite R12 в ОАО «Ростелеком»
Система Oracle E-Business Suite R12 в ОАО «Ростелеком» (далее – Система R12) –
интегрированный комплекс приложений (модулей), объединяющий и автоматизирующий бизнеспроцессы компании на основе единой базы данных.
Система предназначена для автоматизации хозяйственной деятельности компании в следующих
областях:
 Бухгалтерский и управленческий учет
 Налоговый учет
 Управление материальными запасами и закупками
 Договорный учет
 Управление персоналом и расчет ЗП
 Учет основных средств и инвестиционных проектов
 Бюджетный контроль
1.2 Необходимые изменения
Доработки общего характера согласно требований законодательства, с целью автоматизация новых
процессов и отчетных форм, изменения методических указаний по компании, обеспечения
интеграции с внешними системами со стороны R12;
Ниже описаны основные особенности R12 и свод архитектурных решений в разрезе модулей.
 Управление персоналом
В модуле ведется организационная структура, штатное расписание предприятия,
описывается информация о сотрудниках. Хранится информация с учетом изменения по
времени о назначениях сотрудников в штатном расписании предприятия, формируются
документы, отображающие изменения состояния бизнес объектов.
 Табельный учет
Модуль предназначен для сбора и обработки табельной информации сотрудников.
Производится ведение информации об отпусках, больничных, данных учета рабочего
времени. Создается и
передается информация для оплаты отработанного времени,
больничных и отпусков в модуле Зарплата. Происходит деление рабочего времени
сотрудника по процессам. Создаются графики работ.
 Зарплата
Модуль предназначен для расчета и ведения данных о начислениях и удержаниях
заработной платы по назначениям сотрудников организации. Базовым объектом является
элемент начисления или удержания. Значения элементов вводятся вручную, пакетным
вводом, рассчитываются внутренними процессами с использованием специальных формул.

Главная книга
В модуле Главная книга R12 формируется бухгалтерская, налоговая отчетности.
В первичную книгу «ГК РСБУ» осуществляется перенос проводок из модулей Основные
средства (FA), Кредиторы (AP), Дебиторы (AR), Зарплата (PL), Управление материальными
запасами (Inventory), Закупки (PO) через SLA, из модуля Казначейство (TR) с помощью
импорта журналов, а также ввод ручных проводок и загрузка проводок из внешних систем.
В книге «ГК НУ» учет формируется либо регистрами налогового учета в автоматическом
режиме, либо вручную.
Реализована интеграция с КБД, где формируется МСФО учет по Группе компаний
Ростелеком путем сбора первичных данных в терминах РСБУ из локальных систем
филиалов РТК.
Реализована интеграция с системой бюджетирования Hyperion. В ГК РСБУ выгружаются
бюджетные журналы для дальнейшего контроля денежных средств на этапе согласования
договора. На основании данных ГК РСБУ формируется факт по операционной деятельности
для целей бюджетного анализа.
Реализована интеграция с биллинговыми системами в части загрузки в R12 данных по
доходам, расходам, поступлению денежных средств, НДС.
Реализована единая сквозная нумерация и единая форма Авизо во всех модулях,
осуществляющих регистрацию операций ВХР. Реализована единая нумерация и форма
Бухгалтерской справки. Автоматизированы операции, связанные с закрытием счета
отклонений в стоимости ТМЦ. Автоматизирован процесс учета резервов под не
предоставленные документы с целью минимизации трудозатрат на ручной ввод и риска
возникновения ошибки.
 Дебиторы
В модуле ведется учет доходов по непрофильной деятельности и профильным услугам, не
учитываемым в биллинговой системе. Выполняются операции по выставлению счетов,
заведению счетов - фактур и заведению денежных средств. В отдельных случаях
учитываются также выставление услуг и поступления, учитываемые во внешних системах.
Реализовано кастомизированное решение по закрытию дебиторской и кредиторской
задолженности взаимозачетом. Стандартная функциональность OEBS по взаимной
компенсации не используется, т.к. противоречит принятому проектному решению по
оплатам. Автоматизирован расчет дебиторской/кредиторской задолженности в разрезе
контрагентов, документов, сроков образования.
 Кредиторы
Модуль Кредиторы поддерживает выполнение операций, связанных с приобретением услуг,
основных средств, материалов, оборудования и прочих ценностей, а также погашением
задолженности поставщиков и подрядчиков денежными и не денежными средствами.
Реализована модель учета расходов, понесенных в интересах других подразделений с
помощью отдельного сегмента ПС. Автоматизирован механизм загрузки документов по
начислению расходов и формированию документов по начислению НДС в качестве
налогового агента по договорам государственного имущества.
 Управление платежами
 Кастомизированный модуль, предназначеный для инициации платежей по договорам и
прочим выплатам. Основной объект модуля «Счет на оплату». На основе данного объекта
формируются платежи модуля Кредиторы и определенные виды счетов-фактур.
Автоматизирована процедура бюджетного контроля объекта «Резерв ДДС».
 Движение денежных средств
Модуль Движение денежных средств поддерживает обработку банковской выписки и
позволяет осуществлять прогнозирование движения денежных средств.
В R12 реализовано комплексное решение по операционным кассам с целью унификации
работы, оперативного и своевременного контроля остатков, лимитов, излишков и недостач.
Разработан объект «Рабочее место кассира», предназначенный для ввода в R12 сведений о
приходе и расходе денежных средств по кассе в течение операционного дня.
 Активы
Модуль «Активы» предназначен для ведения учета внеоборотных активов организации и
расходов будущих периодов в трех видах учета (РСБУ, НУ, МСФО). Помимо учетных
операций реализован технический учет объектов основных средств, учет в разрезе договоров
с контрагентами, а также аналитический учет в виде отчетности.
При вводе в эксплуатацию внеоборотные активы необходимо классифицировать по коду
ТОУ.
В модуле «Активы» реализована возможность разукрупнять инвентарные объекты ОС –
разделять их на несколько более мелких (выделенных) инвентарных объектов основных
средств. Разработано решение по перемещению активов между региональными филиалами..
По требованиям законодательства в R12 реализованы три правила амортизации:

Линейный: Рассчитывает месячную амортизацию от остаточной стоимости по
остаточному сроку службы.

Нелинейный (для целей НУ): Рассчитывает месячную амортизацию от остаточной
стоимости по норме.

По дням (для РБП): Рассчитывает месячную амортизацию исходя из количества дней
периода, относящихся к действующему договору.
Реализовано решение по ведению региональных налогов, автоматизировано формирование
печатных форм налоговых деклараций. Автоматизировано создание счетов-фактур и
фактических заявок на уплату налога.
 Проекты
Модуль Проекты используется для ведения инвестиционных проектов, а также проектов
РБП, требующих накопления, не включенных в инвестиционных план.
В модуле «Проекты» реализовано комплексное решение по ведению расходов
централизованного проекта. Разработан функционал распределения общих расходов
согласно различным алгоритмам, массового переноса и разбиения затрат проекта.
Предусмотрена единая нумерация карточек активов модулей «Проекты» и «Активы».
 Запасы
Модуль Запасы предназначен для выполнения складских операций с материалами, товарами,
готовой продукцией, товарами отгруженными, оборудованием к установке.
Предусмотрено два способа учета:
1. Учет по единице запаса. Реализуется на базе стандартного метода калькуляции затрат
«ФИФО» и дополнительной кастомизацией по выбору произвольного слоя при списании.
2. Учет по средней скользящей цене. Используется стандартный метод калькуляции затрат
"Средние".
Разработан функционал для выполнения операций списания и перемещения несколько
этапов: создание документа инициатором, его согласование по заранее настроенной цепочке
и проведение сотрудником бухгалтерии.
 Договорный учет
Кастомизированный модуль, предназначенный для регистрации и учета всех типов
договоров: доходный, расходный, финансово-кредитный, доходно-расходный, договор без
суммы и т.д.
Ведется единый реестр договоров по всем типам. Отслеживаются все этапы жизни договора:
от создания до его исполнения.
Есть возможность ведения централизованных расходных и доходных договоров.
Реализовано разграничение доступа к карточкам договоров в разрезе РФ, центра финансовой
ответственности, автора договора. В системе предусмотрено прохождение согласование
договора по заранее настраиваемым цепочкам утверждения.
Регистрация актов выполненных работ/услуг, накладных, создание заявок на оплату из
карточки договора. Наличие договорной аналитики во всех основных модулях .
Автоматизирована процедура бюджетного контроля объекта «Договор».
 Закупки
Модуль Закупки обеспечивает формирование закупочных документов, позволяющими
реализовать потребности в закупке вплоть до отражения в системе поставок приобретенных
позиций.
Реализована форма создания заказа на приобретение из карточки договора.

На базе модуля Закупки реализовано комплексное решение для автоматизации:
o процессов закупочной деятельности в соответствии с положениями федерального
закона РФ от 18.07.2011 г. № 223-ФЗ «О закупках товаров, работ, услуг отдельными
видами юридических лиц»;
o процессов бюджетного контроля, а также обеспечение механизма резервирования
средств бюджета до подписания договора, а именно на этапе формирования заявки;
o процессов закупочной деятельности в соответствии с ПП 932 «Об утверждении
правил формирования плана закупок».
 Налоги
На базе модуля ZX реализовано комплексное решение по формированию книг покупок и
продаж, Деклараций НДС и прочей отчетности по НДС.
 Казначейство
Конфигурация модуля Казначейство поддерживает следующие казначейские операции (в
части формирования паспорта сделки, графика выплат основной суммы, процентов):
 получение, погашение и обслуживание привлечения ДС в форме кредита или займа
(включая овердрафты, транши);
 размещение, возврат, получение дохода и обслуживание размещения ДС в форме депозита
или займа;
 размещение, выкуп, погашение и обслуживание собственных векселей и облигаций;
 покупка, продажа, получение дохода, предъявление к погашению облигаций и векселей 3их лиц;
 покупка, продажа, получение дохода от операций с акциями 3-их лиц и долевых
вложений;


 покупка, продажа, исполнение, получение дохода/расхода от операций с деривативами
хеджирования валютного, процентного, ценового рисков;
Инвестиционное планирование
Кастомизированный модуль, предназначенный для формирования инвестиционного
бюджета и контроля его исполнения при реализации проектов, включенных и утвержденных
в составе инвестиционных планов МРФ/КЦ. Основными объектами модуля являются
карточки проекта и карточка плана. На уровне проекта пользователю доступна информация
по плановым и фактическим показателям в части реализации планов по ДДС, ОКВ и вводу
ОС. Также в модуле реализовано разграничение доступа по организационной и
функциональной принадлежности сотрудника, есть возможность построения моделей
(драфтов) для поиска оптимального набора проектов. На всех уровнях компании реализован
функционал по сбору факта, обоснованию и согласованию план-факт отклонений и
закрытию периода. Модуль полностью интегрирован как со стандартными модулями
(выгрузка инвестиционных проектов, сбор инвестиционного факта) OeBS R12, так и
кастомизированными (решение по бюджетному контролю), интегрирован с внешними
системами: системой бюджетирования Oracle Hyperion и интегрированным комплексом
аналитических инструментов Oracle BI в части централизованного хранения данных и
построения корпоративной отчетности.
 Учет расчетов с международными операторами
Кастомизированный модуль, который позволяет пройти весь цикл обработки документов
расчета с международными операторами. Полностью автоматизированы процессы
взаимозачета, расчета сумм и учета предоплаты/поступления ДС, калькуляции суммы к
оплате и создания СнО, реализовано автоматическое отведение разниц курсов расчета и
комиссии банка, предусмотрена настройка назначения ответственных по каждому отделу с
дополнительным ограничением доступа к выполняемым операциям. Разработаны печатные и
отчетные формы. Разработана функциональность «Поддержка продаж», которая позволяет
своевременно информировать ответственного о просроченной дебиторской задолженности и
определять необходимое мероприятие взаимодействия с оператором. Реализована
интеграция с внешней системой Interconnect, обеспечивающая синхронизацию справочников
(валюты, курсы валют, виды обмена, контрагенты, договора) и документов (транзакции,
счета-фактуры, первичные доходные и расходные счета).
В следующих модулях выполнена корректировка стандартного учета SLA: Зарплата, Кредиторы,
Дебиторы, Активы, Проекты.
Ниже представлен полный перечень бизнес-процессов в разрезе модулей:
RT_BF.015_BFGL2000_Закрытие периода
RT_BF.015_BFGL3000_Загрузка данных из биллинговых систем
RT_BF.015_BFGL4000_Учет резервов по не предоставленным документам
RT_BF.015_BFGL5000_Загрузка бюджета
RT_BF.015_BFAR0040_Учет реализации товаров, работ, услуг, имущественных прав и иных
активов
RT_BF.015_BFAR0050_Ведение договоров и справочников контрагентов
RT_BF.015_BFAR0080_Проведение сверки расчетов с контрагентом
RT_BF.015_BFAR0090_Учет возврата товаров и денежных средств контрагентам
RT_BF.015_BFAR0100_Ведение учета карт оплаты
RT_BF.015_BFAR0110_Погашение дебиторской задолженности собственным векселем покупателя
RT_BF.015_BFAR0140_Учет поступлений денежных средств
RT_BF.015_BFAR0170_Проведение взаимозачета обязательств
RT_BF.015_BFAR0210_Анализ дебиторской задолженности
RT_BF.015_BFAR0230_Учет операций реализации товаров (продукции) по договору комиссии,
поручения
RT_BF.015_BFAR0240_Учет операций сбора платежей от абонентов через агентов
RT_BF.015_BFAR0250_Учет пеней, штрафов, неустоек
RT_BF.015_BFAR0260_Проверка данных модуля Дебиторы перед закрытием периода
RT_BF.015_BFAR0310_Списание безнадежной дебиторской задолженности
RT_BF.015_BFAR0330_Переуступка права требования дебиторской задолженности
RT_BF.015_BFAR0340_Учет операций по возмещению материального ущерба сотрудником
RT_BF.015_BFAR0350_Учет расчетов с персоналом по предоставленным займам
RT_BF.015_BFAR0360_Расчеты с сотрудниками за реализованные товары, работы, услуги, иные
активы
RT_BF.015_BFAR0370_Передача дебиторской и кредиторской задолженности покупателей и
заказчиков между подразделениями компании
RT_BF.015_BFAR0380_Учет расчетов с персоналом по путевкам
RT_BF.015_BFAR0390_Увеличение уставного капитала
RT_BF.015_BFAR0400_Межоператорское взаимодействие в КЦ
RT_BF.015_BFAR0410_Межоператорское взаимодействие в РФ
RT_BF.015_BFCE0100_Импорт банковской выписки
RT_BF.015_BFCE0110_Ввод банковской выписки вручную
RT_BF.015_BFCE0120_Автовыверка банковской выписки
RT_BF.015_BFCE0130_Корректировка выверки банковской выписки в текущем периоде
RT_BF.015_BFCE0140_Выверка банковской выписки вручную
RT_BF.015_BFCE0150_Ведение справочников банков и банковских счетов
RT_BF.015_BFCE0180_Выверка сальдо счетов бухгалтерского учета по счетам банков
RT_BF.015_BFCE0200_Учет аккредитивов в рублях и в иностранной валюте
RT_BF.015_BFCE0210_Регистрация перемещения денежных средств между счетами организации
RT_BF.015_BFCE0220_Учет излишка_недостачи ДС
RT_BF.015_BFCE0230_Регистрация перемещений денежных средств на финансирование
подразделений, возврат финансирования
RT_BF.015_BFCE0240_Выполнение кассовых операций
RT_BF.015_BFCE0250_Выверка данных перед закрытием периода в модуле ДДС
RT_BF.015_BFCE0330_Учет ДС в операционных кассах
RT_BF.015_BFCE0350_Учет корпоративных банковских карт в рублях и иностранной валюте
RT_BF.015_BFCE0370_Регистрация перемещений денежных средств при консолидации доходов
RT_BF.015_BFCE0380_Покупка или продажа валюты
RT_BF.015_BFCE0390_Учет поступления средств целевого финансирования
RT_BF.015_BFCE0400_Прогнозирование ликвидности
RT_BF.015_BFCE0410_Резервирование ДДС
RT_BF.015_BFCE0200_Учет аккредитивов в рублях и в иностранной валюте
RT_BF.015_BFPO0010_Ведение справочника Контрагентов
RT_BF.015_BFPO0020_Ведение договоров
RT_BF.015_BFPO0025_Корректировка Договора
RT_BF.015_BFPO0030_Упрощенное утверждение договора
RT_BF.015_BFPO0035_Комплексное утверждение договора
RT_BF.015_BFPO0040_Приемка МПЗ, услуг
RT_BF.015_BFPO0050_Выполнение возврата поставщику
RT_BF.015_BFPO0060_Закрытие периода в модуле Закупки
RT_BF.015_BFPO0070_Заявки на закупки и выбор Поставщика
RT_BF.015_BFPO0010_Ведение справочника Контрагентов
RT_BF.015_BFIN0010_Управление структурой склада
RT_BF.015_BFIN0020_Ведение номенклатурного справочника
RT_BF.015_BFIN0040_Прочие поступления на склад
RT_BF.015_BFIN0050_Перемещение МПЗ и оборудования к установке между складами разных
филиалов
RT_BF.015_BFIN0060_Перемещение МЗП и оборудования к установке внутри склада и между
складами одного филиала
RT_BF.015_BFIN0070_Выдача из запасов
RT_BF.015_BFIN0090_Проведение инвентаризации
RT_BF.015_BFIN0100_Складской
и
забалансовый
учет
спецодежды,
специнвентаря,
специнструментов
RT_BF.015_BFIN0110_Учет лома драгоценных металлов
RT_BF.015_BFIN0120_Переклассификация МПЗ
RT_BF.015_BFIN0130_Учет товаров отгруженных
RT_BF.015_BFIN0150_Учет ГСМ
RT_BF.015_BFIN0160_Учет имущества, право собственности на которое не перешло к организации
RT_BF.015_BFIN0180_Закрытие отчетного периода
RT_BF.015_BFIN0010_Управление структурой склада
RT_BF.015_BFPL1001_Ввод и корректировка данных для начислений и удержаний
RT_BF.015_BFPL1002_Ввод данных для расчета НДФЛ
RT_BF.015_BFPL1003_Администрирование методов платежа работникам
RT_BF.015_BFPL1004_Ввод данных для платежей третьим сторонам
RT_BF.015_BFPL1005_Учет акционеров и выплата дивидендов
RT_BF.015_BFPL1007_Погашение займов
RT_BF.015_BFPL2001_Расчет аванса
RT_BF.015_BFPL2002_Межрасчет
RT_BF.015_BFPL2003_Расчёты по договорам ГПХ
RT_BF.015_BFPL2004_Расчёты с лицами несписочного состава
RT_BF.015_BFPL2005_Расчет уволенного сотрудника
RT_BF.015_BFPL2006_Расчет отпуска
RT_BF.015_BFPL2007_Расчет заработной платы
RT_BF.015_BFPL2008_Формирование печатной формы 2-НДФЛ
RT_BF.015_BFPL3001_Корректировка заработной платы за закрытые периоды
RT_BF.015_BFPL3002_Корректировка исчисленного налога за закрытые периоды
RT_BF.015_BFPL4001_Формирование проводок по заработной плате
RT_BF.015_BFPL5001_Выплаты по расчетам с персоналом
RT_BF.015_BFPL6001_Закрытие расчетного периода
RT_BF.015_BFPL7001_Формирование персонифицированной отчетности в ПФР
RT_BF.015_BFPL7002_Формирование официальной отчетности в ФСС
RT_BF.015_BFPL7003_Формирование официальной отчетности для Налоговой инспекции (по
НДФЛ)
RT_BF.015_BFPL7004_Формирование официальной отчетности в органы статистики
RT_BF.015_BFPL7005_Формирование управленческой отчетности
RT_BF.015_BFPL7006_Формирование официальной отчетности в ПФР
RT_BF.015_BFHR1101_Ведение юридических лиц и их реквизитов
RT_BF.015_BFHR1102_Ведение обособленных подразделений и их реквизитов
RT_BF.015_BFHR1103_Создание СП
RT_BF.015_BFHR1104_Исключение СП
RT_BF.015_BFHR1105_Исправление ошибки ввода СП
RT_BF.015_BFHR1106_Переподчинение СП
RT_BF.015_BFHR1107_Проектирование и ведение организационной структуры
RT_BF.015_BFHR1108_Проектирование и ведение штатного расписания
RT_BF.015_BFHR1109_Изменение атрибутов СП
RT_BF.015_BFHR1201_Создание ШЕ
RT_BF.015_BFHR1202_Изменение количества ставок ШЕ
RT_BF.015_BFHR1203_Изменение системы оплаты труда на ШЕ
RT_BF.015_BFHR1205_Закрытие ШЕ
RT_BF.015_BFHR1206_Переподчинение ШЕ
RT_BF.015_BFHR1301_Ведение справочника расположений и их реквизитов
RT_BF.015_BFHR1302_Ведение справочника наименований профессий и должностей
RT_BF.015_BFHR2101_Прием на основное место работы
RT_BF.015_BFHR2102_Прием на работу внутреннего совместителя
RT_BF.015_BFHR2103_Мониторинг испытательных сроков
RT_BF.015_BFHR2201_Перевод работника внутри филиала
RT_BF.015_BFHR2202_Перевод работника в другой филиал
RT_BF.015_BFHR2203_Оформление исполнения обязанностей временно отсутствующего
работника
RT_BF.015_BFHR2302_Прекращение внутреннего совместительства
RT_BF.015_BFHR2303_Мероприятия по сокращению численности или штата
RT_BF.015_BFHR2304_Оформление увольнения работника
RT_BF.015_BFHR2400_Оформление и учет договоров ГПХ
RT_BF.015_BFHR3100_Оформление изменения персональных данных
RT_BF.015_BFHR3201_Учет поощрений награждений
RT_BF.015_BFHR3202_Учет назначения и снятия дисциплинарных взысканий
RT_BF.015_BFHR3301_Ведение данных по охране труда
RT_BF.015_BFHR3302_Мероприятия по организации и учету прохождения периодических
медосмотров
RT_BF.015_BFHR3400_Организация воинского учета
RT_BF.015_BFHR4101_Администрирование системы оплаты труда
RT_BF.015_BFHR4102_Установление персональных окладов
RT_BF.015_BFHR4103_Установление персональных доплат и надбавок
RT_BF.015_BFHR4104_Массовое изменение окладов
RT_BF.015_BFHR4201_Постановка согласование целей
RT_BF.015_BFHR4202_Оценка выполнения целей
RT_BF.015_BFHR4203_Расчет премии по целям
RT_BF.015_BFHR4204_Администрирование целей
RT_BF.015_BFHR4205_Расчет периодических премий
RT_BF.015_BFHR4206_Расчет единовременных премий
RT_BF.015_BFHR4207_Расчет ежегодного вознаграждения
RT_BF.015_BFHR4208_Корректировка целей
RT_BF.015_BFHR4301_Оформление документов и регистрация назначения государственных
пенсий
RT_BF.015_BFHR4302_Оформление документов и регистрация назначения негосударственных
пенсий
RT_BF.015_BFHR4303_Перечисление средств в негосударственный ПФ
RT_BF.015_BFHR4304_Оформление страховок
RT_BF.015_BFHR4305_Предоставление гарантий и компенсаций работникам, обучающимся в
образовательных учреждениях
RT_BF.015_BFHR4401_Определение показателей резервов на выплату вознаграждений по итогам
работы за период
RT_BF.015_BFHR4402_Инвентаризация резервов на отпуска и вознаграждения по итогам работы за
период
RT_BF.015_BFHR4403_Инвентаризация расходов по оплате отпусков будущих периодов
RT_BF.015_BFHR4404_Начисление и инвентаризация резерва условных обязательств при
сокращении работников
RT_BF.015_BFTR0010_Привлечение ДС
RT_BF.015_BFTR0020_Размещение ДС
RT_BF.015_BFTR0030_Хеджирование рисков
RT_BF.015_BFTR0040_Расчеты по сделкам
RT_BF.015_BFTR0050_Формирование учета
RT_BF.015_BFTR0060_Формирование отчетности
RT_BF.015_BFAP0010_Расчеты по претензиям, связанным с некачественным товаром
RT_BF.015_BFAP0040_Учет операций по договорам страхования
RT_BF.015_BFAP0070_Учет операций по договорам негосударственного пенсионного обеспечения
RT_BF.015_BFAP0080_Внутрихозяйственные расчеты (с обратной передачей оплаты)
RT_BF.015_BFAP0090_Внутрихозяйственные расчеты (с передачей кредиторской задолженности в
подразделение-приобретатель)
RT_BF.015_BFAP0100_Прямые передачи расходов
RT_BF.015_BFAP0110_Расчеты по аренде гос. имущества
RT_BF.015_BFAP0120_Возврат денежных средств
RT_BF.015_BFAP0150_Начисление и уплата прочих налогов
RT_BF.015_BFAP0160_Выверка расчетов с поставщиком или подрядчиком
RT_BF.015_BFAP0170_Учет операций по приобретению товара по договорам комиссии (по учету
комитента)
RT_BF.015_BFAP0171_Учет операций по приобретению товара по договорам поручения (учет у
доверителя)
RT_BF.015_BFAP0190_Учёт операций приобретения услуг по договору комиссии, когда
комиссионер участвует в расчетах
RT_BF.015_BFAP0200_Проверка данных модуля Кредиторы перед закрытием периода
RT_BF.015_BFAP0220_Учет пеней, штрафов и неустоек у уплате
RT_BF.015_BFAP0240_Учет расчетов с поставщиками и подрядчиками по договорам куплипродажи и подряда
RT_BF.015_BFAP0260_Учет расчетов по уплате госпошлины и судебных издержек
RT_BF.015_BFAP0270_Учет операций по погашению задолженности неденежными средствами
RT_BF.015_BFAP0271_Списание дебиторской задолженности
RT_BF.015_BFAP0280_Учет операций по покупке Организацией права требования долга
RT_BF.015_BFAP0350_Учет товарообменных операций
RT_BF.015_BFAP0360_Учет неотфактурованных поставок
RT_BF.015_BFAP0370_Учет коммерческих кредитов
RT_BF.015_BFAP0410_Учёт расчетов с подотчетными лицами по командировочным расходам
RT_BF.015_BFAP0411_Учёт расчетов с подотчетными лицами по хозяйственным операциям
RT_BF.015_BFAP0420_Учет начисления и выплаты дивидендов
RT_BF.015_BFAP0430_Поступление и оплата по договорам лизинга на уровне КЦ (ГД МРФ)
RT_BF.015_BFAP0431_Поступление и оплата по договорам лизинга на уровне РФ (на балансе
лизингополучателя)
RT_BF.015_BFAP0440_Расчеты по договорам лизинга на балансе лизингодателя
RT_BF.015_BFAP0450_Учет дополнительных соглашений по договору лизинга ( на балансе
лизингополучателя)
RT_BF.015_BFAP0461_Расчеты по импортным контрактам при закупке услуг
RT_BF.015_BFAP0470_Учет операций по созданию и использованию резервного капитала
RT_BF.015_BFAP0480_Учет операций уменьшения собственного капитала
RT_BF.015_BFAP0490_Инициация платежа
RT_BF.015_BFAP0500_Формирование пакетов платежей
RT_BF.015_BFAP0510_Учет операций с проездными документами
RT_BF.015_BFZX0010_Формирование отчетности по НДС
BFTX0010 : Формирование отчетности по налогу на прибыль
RT_BF.015_BFFA0110_Постановка на учет ВА
RT_BF.015_BFFA0120_Постановка на учет ВА по договорам операционной аренды, лизинга
RT_BF.015_BFFA0140_Начисление амортизации, корректировка амортизации прошлых периодов
RT_BF.015_BFFA0150_Прогноз амортизации
RT_BF.015_BFFA0170_Перемещение ОС, НМА внутри РФ между структурными подразделениями,
между МОЛ. Смена расходных счетов
RT_BF.015_BFFA0180_Перемещение объектов ОС, НМА между региональными филиалами
RT_BF.015_BFFA0190_Выбытие капитализированных ВА (частичное и полное, за исключением
реализации)
RT_BF.015_BFFA0200_Реализация капитализированных внеоборотных активов
RT_BF.015_BFFA0210_Разукрупнение ВА (полное и частичное)
RT_BF.015_BFFA0230_Переоценка основных средств, НМА
RT_BF.015_BFFA0240_Инвентаризация ОС, НМА
RT_BF.015_BFFA0250_Инвентаризация драгметаллов в составе ОС
RT_BF.015_BFFA0260_Изменение стоимости имущества, полученного по договору лизинга
RT_BF.015_BFFA0270_Переход права собственности по лизинговому имуществу. Возврат
имущества
RT_BF.015_BFFA0280_Передача основного средства в аренду
RT_BF.015_BFFA0290_Страхование основных средств
RT_BF.015_BFFA0300_Передача основного средства в залог
RT_BF.015_BFFA0310_Консервация ОС. Расконсервация ОС
RT_BF.015_BFFA0320_Регистрация
(аннулирование)
прав
собственности
на
объекты
недвижимости. Регистрация объекта связи в ГСН
RT_BF.015_BFFA0330_Оперативное, доверительное управление, безвозмездное пользование
RT_BF.015_BFFA0340_Учет убытков от реализации объектов ОС, а также расходов НИОКР, не
давших результата
RT_BF.015_BFFA0380_Закрытие периода и периодические процедуры
RT_BF.015_BFFA0390_Учет объектов недвижимости
RT_BF.015_BFFA0400_Формирование отчетности по региональным налогам (транспортный,
земельный, налог на имущество)
RT_BF.015_BFFA0510_Ввод в эксплуатацию объектов РБП, не требующих накопления
RT_BF.015_BFFA0520_Ввод в эксплуатацию объектов РБП, требующих накопления
RT_BF.015_BFPA0010_ Создание и корректировка проекта и его бюджетов
RT_BF.015_BFPA0011_Создание (корректировка) структуры проекта
RT_BF.015_BFPA0012_Ведение централизованных проектов
RT_BF.015_BFPA0100_Перенос расходов между проектами и задачами
RT_BF.015_BFPA0130_Модернизация, реконструкция ОС
RT_BF.015_BFPA0140_Выбытие КВ
RT_BF.015_BFPA0150_Инвентаризация КВ
RT_BF.015_BFPA0160_Инвентаризация РБП
RT_BF.015_BFPA0170_Формирование отчетности выверка и закрытие периода
RT_BF.015_BFPA0180_ План-фактный анализ инв. деятельности и экспорт факт. данных из м.
Проекты OeBS в СИП COMSHARE
RT_BF.015_BFPA0060_Отпуск материалов в инвестиционную деятельность
RT_BF.015_BFPA0070_Выдача оборудования к установке, оборудования не требующего монтажа,
отдельных объектов ОС со склада в монтаж, на строительные площадки и места будущей
эксплуатации.
RT_BF.015_BFPA0080_Поступление прочих расходов по проекту
RT_BF.015_BFPA0090 _Межфилиальное перемещение
RT_BF.015_BFPA0110 _Распределение расходов согласно базе распределения.
RT_BF.015_BFPA0120_Ввод ОС/доходных вложений в МЦ в эксплуатацию
RT_BF.015_BFPA0121 _ Ввод НМА в эксплуатацию
RT_BF.015_BFPA0122 _Ввод НИОКР в эксплуатацию
RT_BF.015_BFPA0200 _Создание/корректировка проекта и его структуры для учета объектов РБП
RT_BF.015_BFPA0030_Отражение выполненных подрядной организацией работ или оказанных
услуг в рамках инвестиционной деятельности
RT_BF.015_BFPA0031_Капитализация командировочных расходов
RT_BF.015_BFPA0032 _Поступление оборудования не требующего монтажа и отдельных объектов
ОС
RT_BF.015_BFPA0040 _Капитализация процентов
RT_BF.015_BFPA0050 _Поступление расходов по оплате труда на инвестиционную деятельность
RT_BF.015_BFTM1101_Ввод нового шаблона графика
RT_BF.015_BFTM1102_Создание графика сменности
RT_BF.015_BFTM2101_Ведение и закрытие табеля
RT_BF.015_BFTM2102_Исправление табеля в закрытом периоде
RT_BF.015_BFTM2201_Оформление сверхурочной работы
RT_BF.015_BFTM2301_Учет работы в режиме неполного рабочего времени
RT_BF.015_BFTM2401_Оформление работы в выходной или нерабочий праздничный день
RT_BF.015_BFTM2501_Оформление и учет листков нетрудоспособности
RT_BF.015_BFTM2601_Составление графика отпусков
RT_BF.015_BFTM2701_Оформление и учет отпусков
RT_BF.015_BFTM2702_Отзыв из отпуска
RT_BF.015_BFTM2801_Оформление и учет направления в командировку
RT_BF.015_BFTM2802_Оформление и учет завершения командировки
Услуги по доработке и развитию Консолидационной Базы Данных (КБД) на основе Oracle
E-Business Suite R12 в ОАО «РОСТЕЛЕКОМ»
2.1 Сведения о системе Консолидационной Базы Данных (КБД) на основе Oracle E-Business
Suite R12 в ОАО «РОСТЕЛЕКОМ»
2
Консолидационная база данных (КБД) на основе приложений Oracle e-Business Suite R12 –
интегрированный комплекс приложений (модулей), объединяющий и автоматизирующий
следующие бизнес-процессы компании:
 Ведение общей организационной структуры и единого справочника должностей
объединенной компании ОАО «Ростелеком»;
 Сбор и консолидацию данных о движениях персонала в рамках объединенной компании;
 Хранение и подготовку данных для получения сводной и аналитической отчетности по
персоналу в различных разрезах;
 Передачу необходимых данных об организационной структуре, штатных позициях,
назначениях на штатные позиции и вакансиях для внешних информационных систем;
 Сбор и консолидацию учетной информации по всем филиалам ОАО «Ростелеком» и
дочерних компаниях группы;
 Трансформацию данных учета на план счетов МСФО;
 Ведение данных и подготовку автоматизированных корректировок для целей МСФО и
управленческого учета;
 Формирование внутренней сводной отчетности объединенной компании для целей
управленческого учета;
 Формирование внешней отчетности группы по стандартам МСФО;
 Передачу данных учета во внешние системы для целей экономического анализа
В планы работ по развитию консолидационной базы данных на основе Oracle E-Business Suite R12
входит дальнейшее развитие функционала КБД в части поддержки и обеспечения процессов учета и
формирования отчетности по МСФО;
2.2 Характеристика объекта автоматизации
Ниже описаны основные особенности Консолидационной Базы Данных на основе Oracle e-Business
Suite R12и свод архитектурных решений в разрезе модулей.
 Главная книга
В модуле Главная книга R12 собирается бухгалтерская информация, получаемая на
периодической основе из первичных учетных систем.
В первичную книгу «ГК РСБУ» через кастомизированный интерфейс осуществляется
передача агрегированных проводок из модулей Главная книга учетных систем
Макрорегиональных филиалов ОАО «Ростелеком» и ряда Дочерних компаний группы. С
помощью кастомизированных загрузчиков WebADI путем импорта журналов производится
загрузка необходимых корректировок.
В книгу «ГК МСФО» выполняется загрузка данных учета по Дочерним компаниям,
использующим Упрощенную модель перекладки данных РСБУ на план счетов МСФО. Из
книги РСБУ осуществляется трансформация данных учета из плана счетов РСБУ на план
счетов МСФО. Через кастомизированные загрузчики WebADI в книгу загружаются данные о
внутригрупповых оборотах компаний группы и в книге производится их выверка и
элиминация.
В книгу МСФО осуществляется импорт автоматизированных корректировок по МСФО из
модуля Модель учета лизинга.
Остальные корректировки загружаются через WebADI кастомизированными загрузчиками.
В книге МСФО формируется учет по МСФО по группе компаний Ростелеком.
Для формирования оперативной, внутренней и внешней отчетности разработан набор
отчетов.
Реализована интеграция с системами Раздельного учета (РУ), и с системой бюджетирования
Hyperion.
 Модель учета лизинга
Разработанный модуль Модель учета лизинга предназначен для ведения финансовых
сведений о договорах лизинга, поддержки графиков платежей и автоматизированного
расчета корректировок по МСФО в части лизинговых внеоборотных активах (ВА).
Рассчитанные корректировки автоматически загружаются в ГК МСФО.
Для контроля операций в модуле предусмотрен ряд отчетов.
3
Объем необходимых услуг
Необходимый объем услуг по доработке и развитию ERP Системы на базе Oracle E-Busines Suite
R12 (включая КБД) в ОАО «Ростелеком» составляет 4000 чел/дней (п.3.1. проекта Договора).
Оценочное распределение трудозатрат между модулями:
Модуль
Главная книга(GL)
Дебиторы(AR)
Денежные средства(CE)
Договорный учет(CN)
Закупки(PO)
Запасы(IN)
Заработная платаPL)
Инвестиционное планирование
Кадровый учет(HR)
Казначейство(TR)
Кредиторы(AP)
Налоги НДС(ZX)
Налоги ННП(TX)
Основные средства(FA)
Проекты(PA)
Количество человеко-дней
250
250
200
250
250
250
250
200
250
100
250
200
200
300
200
Табель(TM)
Технические OEBS R12 (FND)
УМЭС
КБД (HR, GL, МУЛ)
100
150
150
200
Распределение трудозатрат между модулями ERP системы будет уточняться в соответствующих
заказах к договору.
4
Порядок оформления и предъявления результатов услуг
По результатам выполнения Заказов Исполнитель обязан предоставлять соответствующие
результаты и материалы согласно методологии ведения работ Oracle AIM for BF.
В частности, при выполнении доработок системы Oracle E-Business Suite R12 обязательным
является составление документов:
 MD050 – Функциональные спецификации на разработку программных расширений системы
 MD070 – Техническая документация расширений системы (опционально для сложных
доработок)
 BF016 – Функциональные спецификации по настройке модулей (в случае изменения
настроек)
 DO070 – Руководства пользователей (в случае необходимости внесения изменений в
инструкции)
Необходимость доработки прочих проектных документов, в том числе методологических,
согласовывается при заключении соответствующих Заказов.
5
Виды услуг, оказываемые по Договору в рамках Заказов
На основании содержания Заказа и в рамках совместно согласованных объемов Исполнитель
оказывает следующие виды услуг по доработке и развитию ERP системы на базе Oracle E-Business
Suite R12:
1. Услуги по проведению обследования, анализу, разработке новых бизнес-процессов, анализу
эффективности существующих и выработке предложений по их оптимизации;
2. Услуги по проектированию новых и модификации существующих экранных и/или отчетных
форм ERP системы, интеграции с внешними системами
3. Услуги по разработке новых и модификации существующих экранных и/или отчетных форм
ERP системы, интеграции с внешними системами
4. Услуги по администрированию, настройке, управлению, поддержанию архитектурной
целостности ERP Системы
5. Услуги по разработке пользовательской документации (инструкций конечного пользователя)
и методических указаний по работе в ERP системе;
6. Услуги по проведению тестирования, как отдельных компонентов ERP системы, так и по
проведению интеграционного тестирование нескольких компонентов системы
7. Услуги по конвертации данных в ERP систему из замещаемых систем
8. Услуги по обучению и патронажу конечных пользователей на этапе запуска системы в
подразделениях компании
Требования к доработке и развитию ERP системы на базе Oracle E-Business Suite R12 в
ОАО «РОСТЕЛЕКОМ»
6.1 Услуги по доработке и развитию системы ERP системы в ОАО «Ростелеком» должны
оказываться в соответствии с Регламентом управления изменениями функциональности для
OeBS R12 (Приложение 1 к Техническим требованиям)
6
Для регистрации доработок Системы R12 в компании ОАО «Ростелеком» должна
использоваться система JIRA. Реализация любой доработки требует создания запроса на
изменение в данной системе. В соответствии с регламентом трудозатраты согласовываются
Исполнителем и Заказчиком в ходе рассмотрения запроса.
6.2 На доработки выполненные в ходе оказания услуг должна распространяться гарантия – 3
месяца. Дефекты выявленные в течение данного срока должны устраняться в соответствии с
Регламентом исправления дефектов OeBS R12 (Приложение 2 к Техническим требованиям)
6.3 Услуги по доработке и развитию ERP системы в ОАО «Ростелеком» должны включать
методологическое сопровождение и обоснование, под которым подразумевается разработка или
актуализация используемых в ОАО «Ростелеком» методик, учетных политик и пр.
6.4 Услуги по доработке и развитию ERP системы в ОАО «Ростелеком» должны оказываться
эффективной проектной командой, организованной на основе формализованного подхода
Исполнителя к организации проектных команд, основанного на лучших мировых практиках
6.5 Управление оказанием услуг по доработке и развитию ERP системы в ОАО «Ростелеком»
должно основываться на формализованных подходах Исполнителя:
a.
b.
c.
к управлению ходом оказания услуг
к решению открытых вопросов в ходе оказания услуг
к внесению изменений в рамки оказания услуг
6.6 Услуги по доработке и развитию ERP системы в ОАО «Ростелеком» должны проводиться строго на
основе формализованных подходов Исполнителя:
d.
e.
f.
g.
к проектированию решения на Oracle e-Business Suite;
к созданию доработок (включая документирование в соответствии с методологией Oracle AIM for BF)
к тестированию в рамках оказания услуг (включая нагрузочное и регрессионное тестирования автоматизированными
средствами)
к обучению пользователей (включая дистанционное обучение)
6.7 Для эффективного управления проектом в команде исполнителя обязательно должны присутствовать по
2 менеджера (функциональных и технических) и одному архитектору по каждому из направлений:
Финансы, Логистика и Персонал. Также руководители проектов R12 и КБД, функциональный
архитектор и технический архитектор по каждому и проектов.
6.8 К специалистам исполнителя предъявляются следующие требования, которые должны быть
подтверждены предоставляемыми резюме:
Роль специалиста
Требования
Менеджер проекта Oracle eBusiness Suite





Архитектор проекта Oracle
e-Business Suite




Функциональный
консультант по Oracle eBusiness Suite




Технический консультант
(разработчик) по Oracle eBusiness Suite


Опыт работы с Oracle e-Business Suite не менее 5 лет
Опыт руководства минимум 2-мя проектами по доработке,
развитию и внедрению Oracle e-Business Suite в компаниях, с
количеством пользователей более 15000
Владение полноценным набором знаний и навыков проектного
управления
Знание методологии внедрения Oracle AIM, опыт подготовки
проектной документации в соответствии с методологией AIM
Опыт руководства проектной командой от 15 человек
Опыт работы с Oracle e-Business Suite не менее 5 лет
Опыт участия минимум в 2-х проектах по доработке, развитию
и внедрению Oracle e-Business Suite в компаниях, с
количеством пользователей более 15000
Знание модулей Oracle e-Business Suite (Финансы, Логистика,
HRMS)
Опыт разработки функциональной и технической архитектуры
решений на базе Oracle e-Business Suite
Опыт работы с Oracle e-Business Suite не менее 2 лет
Опыт участия проектах по доработке, развитию и внедрению
Oracle e-Business Suite в компаниях, с количеством
пользователей более 15000
Знание модулей Oracle e-Business Suite (Финансы, Логистика,
HRMS. Опыт подготовки документации в соответствии с
методологией AIM
Опыт проведения тестирования разработанных решений
Опыт работы с Oracle e-Business Suite не менее 2 лет
Знание модулей Oracle e-Business Suite (Финансы, Логистика,
HRMS)
 Опыт участия проектах по доработке, развитию и внедрению
Oracle e-Business Suite в компаниях, с количеством
пользователей более 15000
 Знание языков программирования на сервере БД: SQL, PLSQL
 Для технических консультантов по OEBS: Владение навыками
разработки экранных форм Oracle Forms и отчетов (XML, XSL)
 Опыт подготовки технической документации в соответствии с
методологией AIM по разработанным решениям
Описание процедуры оказания услуг и взаимодействия специалистов со стороны заказчика и со
стороны исполнителя приведены в Приложении № 3 к настоящим Техническим требованиям.
Приложение № 1
к Техническим требованиям
Регламент управления изменениями функциональности для OeBS R12
Назначение
Данный регламент описывает действия по централизованному контролю изменений
функциональности ERP Системы, используемой в ОАО «Ростелеком».
Контроль изменений в ERP Системах должен быть централизованным, так как влияние данного
процесса распространяется на все структуры и подразделения ОАО «Ростелеком», которые
используют в своей деятельности функционал или данные из ERP Систем.
Термины, определения и сокращения
Для целей данного регламента в нем определены следующие термины и сокращения.
Система, ERP Система – система автоматизации хозяйственной деятельности ОАО «Ростелеком»
на базе OeBS R12, развитие которой контролируется данным документом.
СОЗ – система отслеживания задач. ПО, позволяющее фиксировать задачи по разработке и
отслеживать их статус (например, Jira, Service Manager, Service Desk и т.п.). Для процесса
управления изменениями используется СОЗ Jira РТК (http://ihelp.rt.ru/).
Расширение ERP Системы – совокупность настроек Системы и объектов кода и соответствующей
им документации, в рамках которой реализуется функционал, отсутствующий в базовой Системе
OeBS R12. Каждое расширение Системы имеет свой код вида XXMMZZZ, где MM – короткое имя
модуля OeBS R12, ZZZ – номер расширения.
Доработка ERP Системы – добавление новой или изменение существующей функциональности
ERP Системы и написание сопутствующей документации. Этот процесс может требовать
дополнительных настроек Системы, проектирования и создания программного кода, различных
сущностей и компонент системы OeBS, и т.д. Если доработка ведётся не в рамках уже
существующих расширений, то требуется регистрация нового расширения с присвоением ему кода
расширения.
Запрос на Изменение, ЗнИ – должным образом оформленная запись в СОЗ, являющаяся
основанием для проведения изменений (доработки) в ERP Системе.
Ключевой пользователь, КП – пользователь ERP Системы, хорошо знакомый с функционалом
Системы и хорошо представляющий себе бизнес-процессы своей предметной области (и возможно
смежных областей), у которого можно уточнить требования к изменениям Системы и
необходимость таких изменений со стороны бизнеса, согласовать предполагаемые изменения в
функционировании Системы, и который может квалифицированно принять результаты
выполненной доработки.
Функциональный Архитектор Системы, ФА – лицо, отвечающее за целостность развития ERP
Системы.
Функциональный консультант, ФК – аналитик, знающий Систему на функциональном уровне.
Инициатор ЗнИ – авторизованное лицо, инициирующее изменения в Системе заведением ЗнИ,
обычно Ключевой пользователь.
Куратор ЗнИ – лицо, курирующее полный жизненный цикл ЗнИ, в результате которого изменение
будет отклонено или реализовано в Системе.
Исполнитель доработки – лицо (подразделение), ответственное за подготовку изменений в
Системе.
Change Advisory Board, CAB, Комитет по Изменениям – регулярно действующий орган,
принимающий решения о необходимости реализации изменений в ERP Системе. Для решения
отдельных вопросов, CAB может привлекать на свои заседания представителей всех сторон,
заинтересованных в изменении функционала Системы.
Менеджер Релизов – лицо, ответственное за формирование Релизов Системы.
Контроль качества (КК) – лицо, отвечающее за проверку соответствия выполненной доработки
всем необходимым стандартам оформления.
Администратор (DBA) – лицо, проводящее технические работы по установке доработок на
тестовые среды с ограниченным доступом и продуктив.
Проектное решение, ПР – проект реализации изменения, представляет собой верхнеуровневое
описание решения, позволяющее однозначно трактовать способ реализации планируемых
изменений и провести первичный анализ их трудоёмкости.
План развития Системы – утверждённые к реализации расширения.
Релиз – набор доработок, готовых к плановой установке на продуктивную среду для ввода в
эксплуатацию.
Хранилище Релизов – хранилище, в котором осуществляется сбор патчей для установки на
продуктивную среду и дальнейшее их хранение для целей аудита.
Регрессионное тестирование – тестирование, целью которого является выявить негативное
влияние на связанную функциональность системы, при установке нового кода расширения.
Интеграционное тестирование – тестирование, целью которого является выявление негативного
влияния доработки на другие части системы.
Общее описание процесса
Из-за высокой степени влияния на все подразделения и всех пользователей ERP Системы,
доработки (расширения) ERP Системы должны контролироваться централизованно.
Под централизованным контролем подразумевается:
сбор исходных требований,
приведение требований к единому внешнему виду (в виде ПР),
централизованная оценка целесообразности предлагаемых изменений в соответствии с
планами развития ERP Системы,
централизованное планирование работ по изменению Системы,
единообразное приёмочное тестирование,
контролируемый ввод в эксплуатацию,
документирование и общий контроль процесса изменения функциональности ERP Системы.
Централизация изменений функциональности ERP Системы осуществляется под контролем
Проектного Офиса КЦ.
Сбор и оформление требований
Требования к изменению функциональности ERP регистрируются централизованно в виде Запроса
на изменение (ЗнИ) в СОЗ.
Источником ЗнИ может стать Запрос на Поддержку (см. Регламент ведения дефектов OeBS R12)
или другие запросы, которые ведутся в той же СОЗ. В таком случае в запросах проставляются
перекрестные ссылки.
При оформлении ЗнИ указывается приоритет доработки:
1. Обязательно (Must have) – критические расширения, без которых ERP Система не
может функционировать.
2. Необходимо (Should have) - расширения, которые являются важными, но не
критическими для ERP Системы.
3. Возможно (Could have) – расширения, реализация которых желательна, но которые
могут быть отложены.
4. Невозможно (Won’t have) – расширения, которые могут быть реализованы сейчас, при
наличии необходимых ресурсов, или оставлены на будущее.
Также указывается ответственное лицо (подразделение), которое является заказчиком требуемого
функционала от бизнеса и Ключевой пользователь (КП), который будет выступать контактным
лицом от бизнеса.
Заведённому ЗнИ автоматически присваивается уникальный код.
После этого ЗнИ назначается на Куратора ЗнИ, который в дальнейшем отвечает за весь жизненный
цикл данного изменения.
Куратор уточняет и утверждает требования и желательные сроки исполнения у КП. Если КП
считает, что требования несущественны, он может закрыть ЗнИ, переведя его в статус Отменён. КП
также может изменить приоритет запроса с соответствующим обоснованием такого изменения в
комментарии.
Результатом данного шага является ЗнИ с:
установленным правильным приоритетом,
подтверждёнными требованиями от бизнеса,
обоснованными желательными сроками реализации.
Определение Проектного решения
Куратор ЗнИ проводит анализ начальных требований с привлечением Функционального
консультанта. По итогам анализа могут возникнуть следующие ситуации:
Функциональность в системе имеется. ФК разъясняет возможности системы Инициатору и
КП. Если разъяснения их удовлетворяют, ЗнИ закрывается с соответствующим
комментарием переводом ЗнИ в статус Отменён.
В Системе имеется недостаток функциональности. ФК определяет, потребуется ли разработка
или можно обойтись изменением настроек. В первом случае он привлекает к анализу
технических специалистов. Результатом работы ФК должно быть Проектное решение (ПР)
и предварительная оценка трудоемкости доработки, которые прикладываются к ЗнИ.
На этом этапе требования могут изменяться, но не кардинально:
Приемлемо: Новое требование: форма должна распределять суммы не только по Серийным
номерам и Партиям, но и по количествам (для позиций с контролем только по количеству).
Неприемлемо: Изменение стратегии: форма должна распределять суммы не на наличное
количество в Запасах, а на строчки расходов в модуле Проекты.
ПР состоит из следующих полей заголовка в ЗнИ:
 Тема
 МРФ-заявитель
 Подразделение-заказчик
 Компоненты
 Идентификатор процесса, документа
 Назначение изменения
 Срок исполнения
 Обоснование
 Последствия в случае [не]исполнения запроса
 Предложения по реализации изменения
 Трудозатраты (чд)
Если в ПР требуется включить дополнительные материалы, то они прикладываются в виде
вложений к запросу с описанием назначения таких вложений в ПР.
Поля ПР (Назначение изменения и Предложения по реализации изменения) должны однозначно
определять, что за доработка должна быть выполнена. После согласования и утверждения запроса,
поля ПР перестают быть доступны для редактирования, а изменение ПР при возврате запроса в
статус Первичного анализа, потребуют пересогласования и переутверждения.
На основе подготовленного ПР делается первоначальная оценка трудоёмкости изменения.
Результатом данного шага является ЗнИ, который дополнительно имеет:
Проектное решение,
предварительную оценку трудоёмкости,
отметка о согласовании ПР с Функциональным архитектором.
Согласование ПР
После написания ПР проводится согласование ЗнИ (переводом в статусе «Согласование») с
тимлидами по функциональному направлению, назначая на него запрос, и далее с Функциональным
архитектором, чтобы исключить принципиально неверное направление развития ERP Системы,
либо реализацию изменений, которые могут привести к логическим противоречиям.
После согласования ФА, запрос назначается на Ключевого пользователя (1го или 2го уровня),
который также согласует доработку и назначает Автором в ЗнИ того Ключевого пользователя
(может быть себя), который далее будет согласовывать ФД и вести приёмочное тестирование.
Результатом данного шага является ЗнИ, который дополнительно имеет:
согласованное Проектное решение,
отметки о согласовании ПР с Функциональным архитектором и Ключевым пользователем,
назначенный Ключевой пользователь, который далее будет согласовывать ФД и вести
приёмочное тестирование.
Ускоренное согласование ПР для технических настроек
В отдельных случаях, когда требуется техническая настройка, не влияющая на бизнес-процессы и
не меняющая функциональность Системы, но с отражением проведённых настроек в документации
(BF.016, BF.170), допускается ускоренное согласование запроса на изменение тимлидом или
Функциональным архитектором. Точный список таких изменений перечислен в Регламенте
изменения настроек, не меняющих функциональность, для ускоренного согласования OeBS R12.
В таком случае ЗнИ из стадии «Согласование» сразу попадает в «Реализацию» с заполнением всех
необходимых отметок о согласовании, а после проведения настроек и проверки сделанных
изменений, ЗнИ закрывается без установки патча.
Решение о необходимости реализации
Подготовленный Куратором ЗнИ с приложенным ПР и предварительной оценкой трудоёмкости
после согласования попадает на рассмотрение в CAB (Change Advisory Board). Решение о
необходимости реализации доработки принимается на заседании CAB, который может привлекать
для уточнения требований и необходимости реализации изменений в Системе заинтересованных
лиц от бизнеса или соответствующие рабочие группы.
Возможность реализации расширений рассматривается строго по приоритету от 1-го к 4-му. По
каждому Запросу на изменение принимается решение: отклонить или утвердить реализацию. Если
решение не может быть принято, оно откладывается до следующего заседания CAB.
На основании принятых к реализации изменений формируется план развития Системы.
В ЗнИ добавляется информация:
Отметка об утверждении CAB,
Предварительный срок реализации.
Заказ реализации
После принятия решения о необходимости реализации, доработка попадает в план разработки с
идентификатором запроса, приоритетом и сроками требуемой реализации. Если изменение требует
создания нового расширения, то после утверждения на заседании CAB, ему присваивается код.
Далее в соответствии с этим планом разработки выполняется детальная оценка трудоёмкости и
возможных сроков реализации исполнителем (исполнителями). Если детальная оценка
трудоёмкости и сроков существенно отличается от предварительной оценки, то ЗнИ может
вернуться на переутверждение в CAB.
После утверждения и документирования трудоёмкости и сроков реализации, доработка отдаётся на
реализацию Исполнителю с проставлением пометки, кто занимается реализацией.
В результате шага процесса в ЗнИ уточняется следующая информация:
код расширения (только для новых расширений),
исполнитель, выполняющий работы по реализации доработки,
согласованные трудоёмкость и срок реализации.
Реализация доработок
Реализация доработки может происходить по собственным правилам Исполнителя ЗнИ, в данном
разделе перечислены только требования, которые должны быть соблюдены в процессе реализации
доработки.
Первым этапом реализации доработки является анализ и написание Функционального дизайна
(MD.050), сценария тестирования (TE.040, опционально), и, при необходимости выполнения
настроек Системы, описания настроек (BF.016). Если выполняется доработка уже существующих
расширений, то изменения вносятся в существующую текущую документацию расширений с
увеличением версий изменённых документов.
Эти документы согласуются с заказчиком доработки от бизнеса (в лице КП) и утверждаются им 1.
На этапе создания и согласования MD.050 могут быть добавлены новые функциональные
возможности:
Приемлемо: Новая функциональная возможность: Для одной и той же партии может быть разная
стоимость. В этом случае давать выбрать отдельно только количества этой партии с одинаковой
стоимостью.
Неприемлемо: Новое требование: форма должна распределять суммы не только по Серийным
номерам и Партиям, но и по количествам (для позиций с контролем только по количеству).
По внесенным изменениям может быть изменена трудоемкость, что потребует повторного
утверждения ЗнИ представителем Проектного офиса.
После утверждения Функционального дизайна, доработка поступает на реализацию разработчику.
В ходе написания кода или постфактум, разработчик также описывает детали технической
реализации в Техническом дизайне (MD.070), кроме тривиальных случаев, когда такая
документация не требуется.
На этом этапе могут меняться только детали выполнения:
Приемлемо: Изменение логики навигационных полей, или фильтров отбора данных. Например:
отбирать только те распределения СФ, по которым создан бухгалтерский учет
Неприемлемо: Форма реализуется в Oracle Forms. Реализовать то же самое, но только в Oracle
Applications Framework.
Далее следуют этапы Code Review и внутреннего тестирования, после успешного прохождения
которых, готовая доработка оформляется в соответствии со Стандартами проектирования и
разработки (MD.010), принятыми на проекте.
Если запрос на изменение является техническим проведением настроек (см. Регламент изменения
настроек, не меняющих функциональность, для ускоренного согласования OeBS R12), не
требующих установки патча, то настройки проводятся непосредственно на продуктиве, отражаются
в BF.016, а запрос закрывается.
Результатом данного шага является:
Согласованная документация к доработке,
Правильно оформленный пакет изменений (патч), готовый к установке.
или (для технических настроек)
Исправленная документация настроек Системы (BF.016),
Проведённые на продуктиве технические настройки.
Приёмочное тестирование
После того, как расширение реализовано, происходит приёмочное тестирование и сбор релиза.
Отобранные в релиз доработки устанавливаются в тестовое окружение на приёмочное тестирование
(UAT, User Acceptance Testing) Ключевым пользователем.
1
Может понадобиться детализация согласования документации к доработке
Результатом тестирования является протокол тестирования (TE.110, необязательно) и отметка об
успешном прохождении тестирования, либо список замечаний, которые передаются Исполнителю
доработки для устранения.
Если в процессе тестирования выявлены недостатки, то доработка возвращается в работу
Исполнителю.
Результатом данного шага является:
Отметка о прохождении приёмочного тестирования,
(необязательно) протокол тестирования,
Правильно оформленный и протестированный пакет изменений (патч), готовый к установке на
продуктив
либо
Протокол замечаний к доработке, выявленных в процессе тестирования.
Сборка релиза и ввод в эксплуатацию
После успешного приёмочного тестирования и (при необходимости)
регрессионного/интеграционного тестирования доработки в соответствии с релизной политикой в
плановые сроки устанавливается на продуктивное окружение и вводится в опытно-промышленную
эксплуатацию: устанавливаются патчи, обновляется документация в Проектной библиотеке. Список
установленных доработок (Release Notes) распространяется по информационным каналам для
информирования всех заинтересованных лиц.
Результатом данного шага является:
Отметка о включении в релиз (с указанием релиза).
Собранный в Хранилище релизов набор протестированных патчей, установленных на
продуктив, и документация к ним.
Патронаж и поддержка доработки
После ввода в опытно-промышленную эксплуатацию, вне зависимости от того, кто являлся
исполнителем доработки, начинается период патронажа доработки, которой продолжается не менее
3 месяцев, если для доработки специально не оговорено другое (например, для доработок, которые
используются только при закрытии года, срок патронажа может быть увеличен до следующего
закрытия года).
Во время патронажного периода доработка проходит технический аудит со стороны службы
поддержки ERP Системы, которая также может определить недостатки в документации и
технической реализации доработки, которые должны быть устранены во время патронажного
периода.
Если во время патронажного периода выявляются недостатки, то они устраняются в рамках
патронажа, а патронажный период продлевается до тех пор, пока все выявленные во время
патронажа недостатки не будут устранены.
После окончания патронажного периода доработка переходит в режим промышленной
эксплуатации и берётся на поддержку.
Сроки исполнения этапов доработки ERP Системы
Следующие шаги и сроки их выполнения определены.
№
Шаг процесса
Ответственный
1.
Приём и первичная обработка
КЦ
требований к изменению
функциональности ERP Системы
2.
Подготовка Проектного решения
Функциональный
консультант
3.
Согласование Проектного решения Функциональный
архитектор
4.
Утверждение плана развития ERP
CAB
Системы и списка утверждённых
Срок исполнения
1 рабочий день
3 рабочих дня
1 рабочий день
Раз в месяц
5.
6.
7.
доработок
Анализ трудоёмкости и сроков
исполнения доработки
Разработка документации к
расширению
Согласование Функционального
дизайна (MD.050) и сценария
тестирования (TE.040)
Разработка расширения
Приёмочное тестирование (UAT)
Патронаж доработки
Исполнитель доработки
2 рабочих дня
Исполнитель доработки
В согласованные сроки
Ключевой пользователь
5 рабочих дней
В согласованные сроки
5 рабочих дней
3 месяца или до
устранения всех
замечаний, выявленных
во время патронажного
периода
При задержке согласования документации к разработке или приёмочном тестировании,
исполнитель доработки информирует Менеджера со стороны Исполнителя и совместно с
уполномоченным представителем Заказчика, указанным в п.1.5, принимается решение либо
остановить услуги по реализации доработки, выставив к зачёту стоимость завершённых этапов
работ; либо считать, что недостатков не выявлено; либо ждать, выставляя к зачёту время ожидания
и сдвигая сроки готовности доработки.
8.
9.
10.
Исполнитель доработки
Ключевой пользователь
Исполнитель доработки
1. Ведение работ в СОЗ
Для ведения работ по изменению функционала ERP Системы используется СОЗ Jira
(http://ihelp.rt.ru/), проект «Развитие OeBS R12», код проекта ERPEXT.
Поля Запроса на изменение
Следующие поля используются в работе над Запросом на изменение
Название поля
Обязат
Описание
ельное
Приоритет
Да
Приоритет реализации доработки
Компоненты
Да
Компоненты Системы (модули), к которым относится
изменение
МРФ-заявитель
Да
Какой МРФ инициировал доработку
ПодразделениеПодразделение бизнеса, заказавшее изменение
заказчик
Заявка SM
Номер заявки из Service Manager или другой системы,
откуда пришёл запрос на изменение
Тема
Да
Краткое название (заголовок) изменения
Описание
Исходный текст запроса на изменение
Идентификатор
Бизнес-процессы, которые затрагиваются данным
процесса, документа
изменением
Код расширения
Код расширения, заполняется только для новых расширений
Назначение изменения Да
Описание доработки, которую требуется реализовать для
выполнения исходных требований
Обоснование
Да
Приводятся причины, по которым необходимо выполнить
доработку, обосновываются сроки реализации (если они
есть)
Срок исполнения
Желаемый срок готовности изменений, если изменения
необходимы к определённому сроку
Последствия в случае
Приводятся ожидаемые выгоды в случае исполнения
исполнения запроса
запроса
Последствия в случае
Приводится негативное влияние в случае отклонения
не исполнения запроса
Предложения по
реализации изменения
Трудозатраты
Занимается
реализацией
Согласовавший Функц.
Архитектор
Да
Да
Да
Функциональный Архитектор, согласовавший проектное
(обязате решение
льно к
простав
лению
перед
отправк
ой на
разработ
ку)
Второй Функциональный Архитектор, согласовавший
проектное решение
Ключевой пользователь, согласовавший проектное решение
Согласовавший Функц.
Архитектор 2
Согласовавший
Ключевой пользователь
Согласовавший ФД
Контроль качества
Да
(обязате
льно к
простав
лению
перед
установк
ой на
промыш
ленный
экземпл
яр)
Провёл UAT
Да
(обязате
льно к
простав
лению
перед
установк
ой на
промыш
ленный
экземпл
яр)
Быстрое изменение
Автор
Исполнитель
запроса
Приводится краткое, но однозначное описание
предлагаемой реализации решения
Трудозатраты на реализацию изменения в человеко-днях
Кому запрос отдан на реализацию
Да
Да
Кто проставил отметку о согласовании ФД
Кто произвёл проверку соответствия доработки принятым
на проекте стандартам
Кто проводил приёмочное тестирование (User Acceptance
Testing, UAT)
Изменение не влияет на функционал, утверждено для
реализации по ускоренной схеме
КП или лицо, его заменяющее
Куратор ЗнИ (или другие исполнители непосредственных
работ по запросу в определённых статусах)
Использование статусов
Следующие статусы используются. Основные статусы, в которых ведётся работа над запросам,
помечены жирным начертанием; [И] обозначает, что действия ожидаются от Исполнителя в
запросе, [А] – от Автора запроса.
Статус
Описание
Кто работает
Открытый
Начальный статус, новый ЗнИ был заведён, требуется
[И] отв. за
назначить ЗнИ на Куратора и взять в работу.
компоненту
Ведётся первичный анализ ЗнИ. Уточняются
[И] Куратор
Первичный
требования, готовится Проектное решение и делается
ЗнИ
Анализ
первичная оценка трудоёмкости.
Проводится согласование запроса ответственными за
[И] отв. за
Согласование
компоненту (модуль) и Функциональными
компоненту,
Архитекторами
Функц.
Архитектор,
КП
Утверждение CAB Проанализированные и оформленные ЗнИ выносятся на [И] CAB
рассмотрение Комитета по изменениям, где
принимается решение о реализации доработки.
Доработка оценивается и назначается на исполнителя,
[И] Куратор
Реализация
отслеживается статус готовности доработки, согласуется ЗнИ
документация доработки, проводится приёмочное
тестирование.
[А] КП
Согласование ФД Проводится согласование документации к доработке
Проводится приёмочное тестирование доработки
[А] КП
Приёмочное
Ключевым пользователем
тестирование
Готовые доработки собираются в Релиз, планируется
[И] Менеджер
Формирование
дата Релиза.
Релизов
Релиза
Приостановлен
Работа над изменением отложена, причина и срок
[И] Куратор
указываются в комментариях ЗнИ.
ЗнИ
Работа над запросом не может продолжаться, КП
[А] КП
Запрошена доп.
необходимо предоставить запрошенную информацию
информация
Установка на
Готовая доработка устанавливается на тестирование на
[И] DBA
тестирование
экземпляр с ограниченным доступом.
Установка на
Готовая доработка в составе Релиза устанавливается на
[И] DBA
продуктив
продуктив.
Выполнен
Изменение выполнено и передано в эксплуатацию.
Отменён
Изменение отклонено и не будет реализовано.
Следующие переходы между статусами определены.
Исходный
Переход статуса,
Статус
Описание шага
Новый статус
Кому
доступен
Открытый
(начальный
статус ЗнИ)
В работу
Начать работу над запросом
Первичный
Анализ
Куратор ЗнИ
Первичный
Анализ
Изменить ПР
Позволяет заполнить поля ПР: Назначение
изменения, Обоснование, Последствия в
случае [не]исполнения, Предложения по
реализации; очищает отметки обо всех
проведённых согласованиях
Первичный
Анализ
Куратор ЗнИ
На согласование
Согласование
Куратор ЗнИ
Отправить ЗнИ на согласование, после
изменения статуса запрос автоматически
назначается на ответственного за компоненту
(тимлида)
Отложить
Отложить работы по запросу, в комментарии
указывается причина, по которой запрос
отложен
Приостановлен Куратор ЗнИ
Запросить информацию
Требуется дополнительная информация для
продолжения работ
Запрошена
доп.
информация
Отменён
Отменить
Доработка не будет выполнена, в комментарии
указываются причины отклонения запроса
Согласование
Куратор ЗнИ
На утверждение CAB
Запрос согласован всеми согласующими и
выносится на утверждение CAB, действие
доступно только после заполнения отметок
всех согласующих
Утверждение
(CAB)
ФА
Вернуть в работу
Есть замечания, ПР необходимо доработать
Первичный
Анализ
ФА
Согласование
Согласование ФА
Проставляется отметка о согласовании ФА,
далее запрос необходимо назначить на второго
ФА
ФА
Согласование
Согласование ФА-2
Проставляется отметка о согласовании вторым
ФА; после проставления отметки, запрос
следует назначить на КП
ФА
Согласование КП
Проставляется отметка о согласовании
Ключевым пользователем, Автором запроса
проставляется КП, который будет
согласовывать ФД к доработке и проводить
приёмочное тестирование
Согласование
КП
Быстрое изменение
Ускоренное согласование настроек, не
вызывающих изменения функциональности
Системы
Реализация
ФА
Отменён
Отклонить
Отклонить запрос без вынесения на CAB, в
комментарии указывается причина отклонения
Утверждение
(CAB)
Куратор ЗнИ
Утвержден
Изменения утверждены и будут реализованы
Реализация
Отменен
Отклонен
Изменения отклонены и не будут реализованы
Вернуть в работу
Требуется внести изменения в ПР
Первичный
Анализ
ФА, отв. за
компоненту
CAB
CAB
Куратор ЗнИ,
CAB
Реализация
Отдать на реализацию
Назначить исполнителя, который будет
заниматься реализацией доработки,
заполняется поле «Занимается реализацией»
Реализация
Согласование
Согласовать ФД
Отправить ФД на согласование Ключевым
ФД
пользователем; к запросу должен быть
приложен ФД, который требуется согласовать;
действие доступно только после назначения
исполнителя, занимающегося реализацией
Куратор ЗнИ
Реализация
Куратор ЗнИ
Реализация
Доработка готова
Доработка полностью готова для приёмочного
тестирования; автоматически заполняется
Резолюция; действие доступно только после
появления отметки о согласовании ФД
Куратор ЗнИ
Реализация
Вернуть в работу
Выявлены замечания, доработка возвращается
в работу; снимаются отметки о Контроле
качества, Приёмочном тестировании и
Резолюция
Куратор ЗнИ
Реализация
Контроль качества
Проставляется отметка о Контроле качества,
что обозначает, что доработка и документация
к ней оформлены в соответствии со всеми
необходимыми стандартами; действие
доступно только после заполнения Резолюции
(то есть, когда доработка готова)
КК(?)
Утверждение
Переутверждение CAB
В результате реализации доработки выявлены (CAB)
существенные изменения в требованиях или в
возможности реализации, что влечёт
существенное изменение трудоёмкости и/или
сроков или требуется изменение ПР, что
требует повторного утверждения CAB
Куратор ЗнИ
Установка на
Установить на приёмочное тестирование
Доработка должна быть установлена на
приёмочное
тестовую среду для приёмочного тестирования тестирование
Ключевым пользователем
Куратор ЗнИ
Изменился ФД
Снять отметку о согласовании ФД
Приёмочное
тестирование
Куратор ЗнИ
Настройки выполнены
Настройки выполнены и отражены в BF016,
запрос закрывается
Выполнен
Куратор ЗнИ
В релиз
Изменение готово к установке на продуктив
Формирование Куратор ЗнИ
Релиза
Принять
Доработка успешно прошла приёмочное
тестирование и может быть установлена на
промышленную среду; автоматически
Формирование КП
Релиза
проставляется отметка о прохождении UAT
Замечания
Есть замечания к доработке, запрос
возвращается в работу; в комментарии
указываются причины возврата в работу;
снимаются отметки о Контроле качества и
Резолюция
Реализация
КП
Установить на приёмочное тестирование
Установить (повторно) патч на экземпляр с
ограниченным доступом для приёмочного
тестирования; запрос автоматически
назначается на администратора (DBA) для
установки
Установка на
приёмочное
тестирование
КП
Формирование Назначить Релиз
Указать имя Релиза, в котором доработка
Релиза
попадёт на продуктив
Формирование Менеджер
Релиза
Релизов
Установка на
На установку
Доработка готова, нужно поставить её на
продуктив
продуктив; запрос автоматически назначается
на администратора (DBA) для установки
Отозвать из Релиза
Вернуть запрос в работу
Реализация
Выполнен
Выполнен без патча
Доработка выполнена без патча, только в виде
настроек на продуктиве или изменения
документации
Установка на
приёмочное
тестирование
Установка на
продуктив
Менеджер
Релизов
Менеджер
Релизов
Менеджер
Релизов
Реализация
DBA
Реализация
Установка не выполнена
Во время установки патча произошли ошибки
DBA
Установка выполнена
Установка патча выполнена успешно, без
ошибок
Отменить установку
Не надо устанавливать патч по каким либо
причинам, отменить установку
Реализация
Куратор ЗнИ
Установка выполнена
Установка патча выполнена успешно, без
ошибок
Выполнен
DBA
Реализация
Установка не выполнена
Во время установки патча произошли ошибки
Отменить установку
Не надо устанавливать патч по каким либо
причинам, отменить установку
DBA
Формирование Менеджер
Релиза
Релизов
Приостановлен Вернуть в работу
Работа с запросом должна быть продолжена
Первичный
Анализ
Куратор ЗнИ
Вернуть в работу
Запрошена
доп. информация Работа с запросом должна быть продолжена
без предоставления информации
Первичный
Анализ
Куратор ЗнИ
Предоставить информацию
В комментарии к запросу или вложениях
необходимая информация предоставлена
Выполнен
-
Отменён
Вернуть в работу
Необходимо вернуть запрос в работу
Первичный
Анализ
КП
Первичный
Анализ
Куратор ЗнИ
Диаграмма статусов в Jira
Легенда (кто работает над запросом в соответствующем статусе):
2.
Приложение А. Шаблон Проектного решения
Название доработки
Список модулей Системы
Компоненты:
Тип:
Автор:
Запрос на изменение
КП
Приоритет:
Исполнитель:
Куратор ЗнИ
МРФ-заявитель:
Подразделение-заказчик:
Заявка SM:
Идентификатор процесса, Коды изменяемых Бизнес-процессов
документа:
Код расширения (только для новых расширений)
Код расширения:
Назначение изменения:
Обоснование:
Последствия в случае
исполнения запроса:
Последствия в случае не
исполнения запроса:
Предложения по
реализации изменения:
Сложность запроса:
Трудозатраты:
Описание
Исходный текст требований к изменению.
3.
Приложение № 2
к Техническим требованиям
Регламент исправления дефектов OeBS R12
Назначение
Данный регламент устанавливает порядок взаимодействия 2го и 3го уровней поддержки
промышленного экземпляра Oracle e-Business Suite R12 в ОАО «Ростелеком». Время выполнения
критических шагов и действий участвующих сторон по данному регламенту находятся в
Соглашении об уровне сервиса (SLA).
Термины, определения и сокращения
Для целей данного регламента в нем определены следующие термины и сокращения.
1-й уровень поддержки, HelpDesk – является единой точкой входа по всем IT-Услугам,
осуществляет регистрацию, первичный анализ и диспетчеризацию обращений на 2-ой уровень
поддержки.
2-й уровень поддержки – аналитики и администраторы, знающие Систему на
функциональном уровне, которые идентифицируют и решают проблемы с помощью
имеющегося функционала Системы на месте возникновения проблем в региональных
отделениях Заказчика. Проблемы по централизованным решениям, требующие изменения
Системы или исправления данных, которые нельзя выполнить с помощью имеющегося
функционала, передаются на 3-й уровень. Также 2-й уровень осуществляет помощь
пользователям в решении нестандартных задач работы Системы: закрытие периодов,
подготовка и выверка данных и т.п. Данная функция осуществляется в ЛЦК.
3-й уровень поддержки – централизованное подразделение из аналитиков и разработчиков,
занимающееся поддержкой стандартной функциональности и расширений Системы, в том
числе взаимодействие с поставщиками ПО и другими третьими лицами, привлечение которых
необходимо для поддержки Системы.
ЛЦК (локальный центр компетенции) – локальное техническое подразделение МРФ,
участвующее в процессе поддержки пользователей, непосредственно взаимодействует с
пользователями Системы, осуществляет работы на месте возникновения проблем. На базе
ЛЦК формируется 2й уровень поддержки Системы.
МРФ – макрорегиональный филиал ОАО «Ростелеком».
ERP Система (просто Система) – программно-аппаратный комплекс, предназначенный для
решения задач автоматизации хозяйственной деятельности ОАО «Ростелеком», для которого
осуществляется техническая поддержка. Если не указано другое, то под Системой
подразумевается R12.
OeBS R12 (или просто R12) – представляет собой экземпляр ERP Системы на основе Oracle eBusiness Suite R12 с настроенными параметрами конфигурации и дополнительно
разработанными расширениями.
Среда с ограниченным доступом – клон промышленного экземпляра Системы, изменения в
виде установки патчей на который могут вносить только администраторы (DBA).
ИСП Jira (Jira РТК) – информационная система поддержки для регистрации и ведения
Запросов по поддержке (дефетов), которая служит для взаимодействия между 2м и 3м
уровнями поддержки. Используется ИСП Jira по адресу http://ihelp.rt.ru/.
САСП Service Manager – система автоматизации службы поддержки пользователей на базе
HP Service Manager, предназначена для ведения взаимодействий между пользователями
Системы и 1м либо 2м уровнем поддержки, размещенная по адресу: https://sd.rt.ru/.
Документация к Системе – пакет документов, описывающих функционирование Системы.
Для стандартной функциональности это Руководства пользователя и другая имеющаяся
документация к Системе от производителя ПО; для расширений это Функциональный дизайн
и другая документация, поставляемая в комплекте с расширением; а также описания Бизнеспроцессов, задокументированные настройки Системы и другая документация, подготовленная
в процессе внедрения Системы. Документация Системы хранится в Проектной библиотеке.
Ошибка – такое поведение Системы, когда Система ведёт себя не так, как описано в
документации к Системе, или возникают сообщения о системных ошибках, или сбои в работе.
Запрос (Запрос на поддержку, ЗнП) – означает специальным образом оформленное и
зарегистрированное в ИСП обращение.
Приоритет запроса – атрибут Запроса в ИСП, определяющий очерёдность и срочность, с
которой Запросы будут обрабатываться.
Время реакции (реагирования) – время, прошедшее между попаданием Запроса в
определённое состояние и выходом его из этого состояния.
Статус запроса меняется в ИСП и характеризует текущее состояние Запроса.
Автор запроса – авторизованный сотрудник 2-го уровня поддержки, уполномоченный
открывать Запросы в ИСП и вести по ним работу.
Исполнитель запроса – сотрудник 3-го уровня поддержки, которому передан Запрос на
исполнение, и который отвечает за решение по Запросу.
Координатор от Заказчика – лицо (лица), ответственное за решение вопросов по
предоставлению Услуг поддержки Системы со стороны Заказчика.
Координатор от Исполнителя – лицо (лица), ответственное за предоставление Услуг
поддержки Системы со стороны Исполнителя.
Общая информация о ведении дефектов
Взаимодействие 2го и 3го уровней поддержки ERP Системы OeBS R12 ведётся в виде обращений
специального вида – Запросов, оформленных в информационной системе поддержки (ИСП) Jira,
которая предназначена для ведения и документирования взаимодействия между 2м и 3м уровнями.
Все Запросы регистрируются и ведутся в ИСП. Текущее состояние запроса отражается в его
текущем статусе. Все действия по исполнению запросов документируются в ИСП Jira:
Информация обо всех значимых коммуникациях по запросу между 2м и 3м уровнями
поддержки (переписка по e-mail, телефонные и др. контакты), произведенных вне учетной
записи по запросу.
Информации обо всех значимых для исполнения запроса событиях.
Информации обо всех полученных значимых промежуточных и окончательных результатах
исполнения запроса.
Обоснования каждого изменения срока исполнения и приоритета запроса.
Обоснования приостановки запроса, закрытия запроса без подтверждения.
При прикладывании файлов – обоснования с указанием названия прилагаемого файла, его
краткого содержания и назначения в рамках данного запроса.
Из ИСП получают регулярную отчётность для слежения за ходом работ и текущей ситуацией.
В случае возникновения нештатных ситуаций (например, недоступности Автора или Исполнителя
запроса, тупиковых ситуациях с Запросами и т.п.) следует довести информацию до Координатора с
указанием номера Запроса.
Время реакции и исполнения отдельных шагов процесса указано в отдельном документе
«Соглашение по уровню сервиса (SLA) для OeBS R122».
Расположение ИСП Jira
ИСП Jira доступна по адресу http://ihelp.rt.ru/ (или по ip-адресу
http://10.160.8.79/, если недоступна служба разрешения имён DNS).
2
Пока такого документа нет
Учётная запись пользователя (кроме редких исключений конфликтов имён) совпадает с именем
пользователя в электронной почте до символа «@».
Для ведения запросов между 2м и 3м уровнями по поддержке OeBS R12 используется канал
(категория) «03.ЦЕНТРАЛИЗОВАННАЯ ПОДДЕРЖКА ERP СИСТЕМ», проект
«Централизованная подержка OeBS R12», код проекта SUPP.
Получение учётной записи
Чтобы получить учётную запись в ИСП Jira, следует обратиться по электронной почте к
руководителю группы, ведущей работы на проекте, а тот в свою очередь перешлёт заявку
Координатору проекта, подтвердив тем самым своё согласие на работы для указанных в письме
лиц. В письме требуется указать ФИО, адрес электронной почты, проект, роль на проекте и
функциональную область. Пример:
Иванов Сергей Петрович, sivanov@________, поддержка OeBS R12, 3й уровень, аналитик,
Проекты
Далее для добавления пользователей непосредственно в ИСП, Координатор заводит заявку в
проекте «Техническая поддержка JIRA» и, если необходимо, делает соответствующие назначения
на роли в проекте.
Восстановление пароля
На экране входа в Jira
выбрать ссылку «Не можете попасть в систему?» и следовать инструкциям.
Роли на проекте и их использование
Следующие роли определены:
Manager осуществляет управление проектом, имеет возможность нестандартных действий
(Координатор).
Developer соответствует 3му уровню (Исполнители ЗнП).
User соответствует 2му уровню (Авторы ЗнП).
Admin – дежурные администраторы (DBA) проекта.
Viewer – роль только для просмотра проекта.
В зависимости от роли, будут доступны разные действия по переходу статусов. Заводить запросы в
проекте могут только пользователи ИСП Jira в роли User; назначать запросы можно только на
исполнителей, имеющих роль Developer. Роль Viewer используется для доступа к проекту на
просмотр, в такой роли нельзя вносить никаких изменений в запросы.
Зона видимости комментариев
Для ограничения видимости комментариев в ЗнП можно использовать роли на проекте.
Роль Developer соответствует 3му уровню поддержки (Исполнителям ЗнП), роль User
соответствует 2му уровню (Авторам ЗнП). Таким образом, комментарии в зоне видимости
Developer будут доступны только 3му уровню и не будут видны 2му.
Не следует злоупотреблять зоной видимости комментариев, допускается ограничивать
информацию, которая действительно не требуется вниманию всех участников процесса, например,
чтобы задокументировать технические детали, найденные в процессе поиска ошибки.
Приоритеты и их использование
Определения приоритетов даны следующим образом
Приоритет
Описание
1-й приоритет (Высший)
Проблема влечет за собой остановку или полную потерю
работоспособности Системы. Становятся недоступными
критические функции Системы, которые препятствуют ведению
бизнеса, и ситуация является критической. Проблемы первого
приоритета обычно имеют одну или несколько из
нижеперечисленных характеристик:
 повреждение данных;
 недоступны функции Системы, задокументированные как
критические;
 Система зависает на неопределенное время, бесконечно
занимая ресурсы и не давая отклика;
 Система аварийно останавливается и не может начать
работать после перезапуска.
Работа будет вестись в круглосуточном режиме 24*7 до решения
проблемы или до тех пор, пока достижим прогресс в ее решении.
2-й приоритет (Высокий) Проблема влечет за собой значительную потерю
работоспособности Системы. Критические функции Системы
становятся недоступными, и нет применимого обходного пути
решения, однако, Система сохраняет работоспособность в
ограниченном объёме, и работы по решению будут вестись в
рабочее время.
3-й приоритет (Средний)
Проблема влечет за собой несущественную потерю
работоспособности Системы, следствием чего является
неудобство в работе или необходимость использовать
альтернативные или обходные пути решения (workaround).
4-й приоритет (Низкий)
Данная проблема не влечет потери работоспособности Системы.
Это незначительная ошибка или неудобство, ошибка в
документации и т.п., которые не препятствуют проведению
операций в Системе.
Первоначально приоритет выставляется при заведении Запроса и определяет очерёдность
обработки и работы над Запросами. В дальнейшем приоритет может быть скорректирован
Исполнителем Запроса, если выставленный приоритет не соответствует реальному положению дел
и нет соответствующих обоснований.
При определении приоритета учитываются следующие основные факторы:
Срочность: высокая, средняя, низкая.
Масштаб влияния: количество повреждённых данных в системе, суммы ущерба, количество
затронутых пользователей.
Другие обстоятельства: взаимодействие с гос. и налоговыми органами, потенциальные
убытки, интересы топ-менеджемента и т.п.
Работа по 1-му приоритету предполагает круглосуточную работу Исполнителя и требует также
круглосуточной доступности от Автора запроса на месте возникновения ошибки для помощи в
сборе данных, тестирования предложенного решения и осуществления исправлений на
продуктивной среде, а также обеспечения круглосуточной доступности тестового окружения, в
котором можно работать над Запросом.
Стандартным при регистрации Запроса является 4-й приоритет, 1-й и 2-й приоритет всегда должны
быть ясно обоснованы, 3-й приоритет может быть обоснован, если его использование для
конкретного Запроса не очевидно из контекста.
При качественном изменении ситуации и появлении новых обстоятельств во время работы над
Запросом, приоритет Запроса может быть пересмотрен в сторону увеличения (эскалация) или
уменьшения (де-эскалация).
Если одна из сторон при работе в Запросе не проявляет активности, определённой временем
реакции, то Запрос доводится до внимания соответствующему Координатору для согласования
дальнейших действий.
При изменении приоритета высокоприоритетных Запросов (эскалация на 1-й и де-эскалация на 2-й
приоритет) или заведении нового Запроса 1-го приоритета требуется обязательное уведомление по
телефону другой стороны и Координатора.
Статусы и их использование
Для отражения текущего состояния Запросов в ИСП Jira РТК используется статус. Переходы из
одного статуса в другой называются действиями или действиями потока работ (workflow).
Описание используемых статусов
Основными статусами являются:
«В работе», в котором 3й уровень занимается поиском решения, и
«Исполнен», в котором 2й уровень проверяет и вводит в эксплуатацию предложенное решение
в соответствии с Политикой релизов.
Следующие статусы используются, основные статусы отмечены полужирным начертанием.
Статус
Описание
Кто
работае
т
Открытый
Начальный статус, новый ЗнП был заведён 2м уровнем,
2й и 3й
требуется взять ЗнП в работу. Такие запросы назначаются
уровень
автоматически на ответственных за компоненту (модуль).
Ведётся работа над решением проблемы, обозначенной в
3й
В работе
ЗнП.
уровень
Ожидается
По ЗнП заведено обращение (SR) в службу технической
3й
исполнение SR
поддержки Oracle или к другому поставщику ПО (4я линия уровень
поддержки), ведётся работа в SR и/или ожидается решение.
Ожидаются мет.
По ЗнП ожидаются методологические рекомендации,
3й
рекомендации
работа не может быть продолжена.
уровень
На согласовании
Требуется согласование по какому-либо вопросу, причина
3й
ожидания должна быть указана в комментарии к ЗнП.
уровень
Приостановлен
Работа над ЗнП остановлена, но может быть продолжена в
3й
дальнейшем. Причина ожидания должна быть указана в
уровень
комментарии.
Запрошена доп.
Для работы по ЗнП требуется дополнительная информация 2й
информация
от 2го уровня (или от пользователей), работа на 3м уровне
уровень
не может быть продолжена. 2й уровень должен
предоставить запрошенную информацию и вернуть ЗнП в
работу.
Приостановлен из-за Запрошенная у 2го уровня информация не предоставляется 2й
отсутствия
слишком долго, работы 3го уровня над ЗнП остановлены;
уровень
информации
если доп. информация не будет предоставлена, то ЗнП
будет закрыт 3м уровнем.
Выпуск патча
Решение подготовлено 3м уровнем, требуется
3й
подтверждение от ответственного за компоненту (тимлида) уровень
Работа над ЗнП выполнена на 3м уровне, решение
2й
Исполнен
представлено в виде ответа на вопрос или в виде
уровень
надлежащим образом оформленных исправлений (патч). 2й
уровень проверяет предоставленное решение и вводит его в
эксплуатацию.
Установка на
Требуется установка патча на экземпляр с ограниченным
DBA
тестирование 3м
уровнем
Установка на
тестирование 2м
уровнем
Установка на
продуктив
Установка на
продуктив срочно
Отменён
Закрыт из-за отмены
Закрыт с
подтверждением
Закрыт без
подтверждения
доступом (указан в последнем комментарии) для
тестирования 3м уровнем.
Требуется установка патча на тестирование 2м уровнем,
экземпляр указан в последнем комментарии.
DBA
Требуется установка патча на продуктив. Предварительно
патч должен быть установлен на среду с ограниченным
доступом и протестирован, чтобы убедиться в
корректности установки патча и вызываемых им
изменений.
Требуется срочная установка патча на продуктив во
внерегламентное время. Предварительно патч должен быть
установлен на среду с ограниченным доступом и
протестирован, чтобы убедиться в корректности установки
патча и вызываемых им изменений. Также при запросе
срочной установки требуется обоснование срочности.
Внимание: срочной установки следует избегать при
любой возможности, так как установка патча в рабочее
время может вызвать проблемы в работе системы,
которые помешают работе всех остальных
пользователей, или привести к полной
неработоспособности системы.
ЗнП был отменён, можно либо закрыть его окончательно,
либо вернуть в работу.
ЗнП закрыт из-за отмены.
ЗнП закрыт 2м уровнем, проблема полностью решена.
DBA
ЗнП закрыт 3м уровнем, без подтверждения от 2го уровня.
-
DBA
2й и 3й
уровень
-
Следующие переходы между статусами определены. Переходы между статусами доступны в
зависимости от роли.
Статус
Переход статуса (id)
Кому доступен
>> новый статус
Открытый
В работе
Принять запрос в работу (11)
>> В работе
Исполнитель
Отменить запрос (21)
>> Отменён
Исполнитель,
Автор
Запросить информацию (31)
>> Запрошена доп. информация
Исполнитель
Исполнить (41)
>> Исполнен
Исполнитель
Отменить (51)
>> Отменён
Автор,
Исполнитель
Приостановить (61)
>> Приостановлен
Исполнитель
Зарегистрирован SR (81)
>> Ожидается исполнение SR
Исполнитель
Ожидать согласования (271)
>> На согласовании
Исполнитель
Запросить мет. рекомендации (301)
>> Ожидаются мет. рекомендации
Исполнитель
Установить на тестирование (321)
>> Установка на тестирование 3м уровнем
Исполнитель
Эскалировать запрос (391)
>> В работе
всем
Согласиться с завершением (91)
>> Закрыт с подтверждением
Автор
Вернуть в работу (101)
>> В работе
Автор,
Исполнитель,
Координатор
Закрыть без подтверждения (111)
>> Закрыт без подтверждения
Координатор
Установить на тестирование (361)
>> Установка на тестирование 2м уровнем
Автор
Установить на продуктив (341)
>> Установка на продуктив
Автор
Установить на продуктив срочно (431)
>> Установка на продуктив срочно
Автор
Предоставить информацию (131)
>> В работе
Автор
Отменить запрос (141)
>> Отменён
Автор
Приостановить запрос из-за длительного
ожидания доп. сведений (151)
>> Приостановлен из-за отсутствия
информации
Исполнитель,
Координатор
Вернуть в работу (381)
>> В работе
Исполнитель,
Координатор
Закрыть из-за отмены (171)
>> Закрыт из-за отмены
Автор,
Исполнитель,
Координатор
Вернуть в работу (181)
>> В работе
Исполнитель,
Координатор
Изменить резолюцию (191)
>> Закрыт из-за отмены
Координатор
Закрыт без
подтверждения
Изменить резолюцию (201)
>> Закрыт без подтверждения
Координатор
Закрыт с
подтверждением
Изменить резолюцию (211)
>> Закрыт с подтверждением
Координатор
Вернуть в работу (221)
>> В работе
Исполнитель,
Координатор
Предоставить долгожданную информацию
(241)
>> В работе
Автор
Исполнен
Запрошена доп.
информация
Отменён
Закрыт из-за отмены
Приостановлен
Приостановлен из-за
отсутствия информации
Закрыть без подтверждения (251)
>> Закрыт без подтверждения
Координатор
Вернуть в работу (181)
>> В работе
Исполнитель,
Координатор
Вернуть в работу (261)
>> В работе
Исполнитель,
Координатор
На согласовании
Вернуть в работу (281)
>> В работе
Исполнитель,
Координатор
Ожидаются мет.
рекомендации
Вернуть в работу (291)
>> В работе
Исполнитель,
Координатор
Установка на
тестирование 2м уровнем
Установка выполнена (351)
>> Исполнен
DBA
Отменить установку (421)
>> Исполнен
Автор,
Координатор
Ожидается исполнение
SR
Установка на продуктив Установка выполнена (351)
>> Исполнен
Установка на
тестирование 3м уровнем
Отменить установку (421)
>> Исполнен
Автор,
Координатор
Установка выполнена (371)
>> В работе
DBA
Отменить установку (411)
>> В работе
Исполнитель,
Координатор
Установка на продуктив Установка выполнена (451)
>> Исполнен
срочно
Выпуск патча
DBA
DBA
Отменить установку (461)
>> Исполнен
Автор,
Исполнитель,
Координатор
Вернуть в работу (491)
>> В работе
Автор,
Исполнитель,
Координатор
Подтвердить исполнение (501)
>> Исполнен
Ответственный
за компоненту,
Координатор
Диаграмма статусов и переходов между ними
Открытый
Ожидается
исполнение SR
Приостановлен
Ожидаются мет.
рекомендации
Запрошена доп.
информация
На согласовании
В работе
Приостановлен
из-за отсутствия
информации
DBA
Установка на
тестирование 3м уровнем
Выпуск
патча
Установка на
тестирование 2м
уровнем
Исполнен
Установка на продуктив
Отменён
Закрыт из-за отмены
Установка на продуктив
срочно
Закрыт без
подтверждения
Закрыт с подтверждением
Легенда: кто работает над запросом
2й уровень
3й уровень
DBA
Требования к оформлению Запросов
При оформлении Запроса, Автор заполняет следующие поля заголовка:
МРФ-заявитель
никто
Приоритет
Компонента – модуль ERP Системы
Заявка SM – номер инцидента из САСП Service Manager для обратной связи
Номер расширения – расширение, в котором обнаружена ошибка (если ошибка произошла в
работе расширения)
Тема – краткое в одну строку описание проблемы, которое отражает суть проблемы и станет
заголовком ЗнП
Описание проблемы: детальное описание проблемы, которое должно включать:
 точное название полномочий;
 полный путь навигации;
 подробный пошаговый сценарий воспроизведения проблемы;
 воспроизводима ли проблема, если повторить сценарий воспроизведения
(воспроизводима
всегда,
воспроизводима
при
определённых
условиях,
невоспроизводима), воспроизводится ли проблема на всех экземплярах Системы или
только на некоторых (указать на каких);
 изображения экрана с ошибкой (если применимо); если в диалоге есть кнопка
«Подробнее», то нажать и сделать дополнительно снимок экрана с более подробным
сообщением об ошибке;
 если проблема возникла с отчётом, то указать точное название отчёта, request_id запуска,
параметры запуска, приложить вывод отчёта (если есть) и файл журнала;
 пояснение на конкретном примере, что выдаёт Система, что должна выдавать и почему;
 продолжает ли Система работать нормально после появления ошибки, блокирует ли
ошибка полностью работу над бизнес-процессом или работа может быть продолжена
каким-либо образом, насколько критический бизнес-процесс затронут;
 имеется ли дополнительная информация, которую следует принять к сведению: масштаб
проблемы, критические даты (например, закрытие периода, подача отчётности в
государственные органы и т.д.), затронуты ли VIP-персоны и т.п. Если запрос заводится
с повышенным приоритетом, то требуется указать обоснование приоритета;
 явно сформулированный результат исполнения запроса (например, требуется
исправление данных).
При необходимости прикладываются другая поясняющая информация в виде файлов (снимки
экрана с ошибками, сформированные результаты отчётов с поясняющими пометками и
т.п.). Если файлов много, то их можно приложить сразу после создания запроса. При
загрузке таких файлов требуется сделать комментарий с указанием названия прилагаемого
файла, его краткого содержания и назначения в рамках данного запроса.
Принятые сокращения для описания работы в Системе:
(Н) – Навигатор (основное меню модуля)
(Ф) – форма
(К) – кнопка экранной формы
(М) – меню приложения
ОГП – описательное гибкое поле
КГП – ключевое гибкое поле
Один Запрос должен соответствовать одной проблеме. Если проблем будет описано больше одной,
то Исполнитель вправе перевести запрос в статус «Исполнен» после подготовки решения первой
же из перечисленных проблем. Для остальных проблем следует завести новые запросы (например,
клонировав исходный Запрос с соответствующими исправлениями в описании).
Если возникает новый случай проявления проблемы, аналогичный уже открытому запросу, то его
следует указать в комментарии к запросу. Если этот новый случай проявления проблемы не может
быть решен в рамках имеющегося запроса (например, решение уже подготовлено, и оно не
включает в себя новый случай, или работа над новым случаем приведёт к нежелательным
задержкам в решении), то следует завести новый Запрос со ссылкой на уже имеющийся.
Взаимодействие с 4м уровнем поддержки
Когда проведение работ требует обращения 3го уровня к другим службам и подразделениям, не
участвующим в работе на 3м уровне поддержки, в том числе третьим организациям (так
называемый 4й уровень поддержки), 3й уровень оформляет соответствующие заявки в других
информационных системах. Ниже приведены такие случаи.
После заведения заявки во внешней информационной системе, её номер заносится в специальное
поле в заголовке Запроса (Номер SR/Заявки в SD) и Запрос переводится в статус «Ожидается
исполнение SR».
Так как взаимодействие с 4м уровнем поддержки может вызвать задержки в решении Запроса,
целесообразно рассмотреть возможность проработки временного обходного пути решения
проблемы, описанной в Запросе, с соответствующим понижением приоритета.
Обращение за методологической поддержкой
Для запросов по методологической поддержке обращения заводятся в виде запросов в ИСП Jira по
каналу «02.МЕТОДОЛОГИЯ», проект «Методология учета». После открытия запроса, требуется
установить связь между ЗнП и методологическим запросом.
Обращение к глобальной службе поддержки Oracle
Обращение к глобальной службе поддержки Oracle происходит по проблемам стандартной
функциональности OeBS. Обращения регистрируются на портале MyOracleSupport
(http://support.oracle.com).
Technical Support Policies http://www.oracle.com/us/support/policies/index.html
Обращение к службе поддержки Borlas
Обращения к службе поддержки компании Borlas ведутся по вопросам локализации модуля HR
OeBS, как поставщика данного решения. Запросы регистрируются на портале
https://techsup.borlas.ru/
Сквозной процесс работы над Запросом
Сквозной процесс работы над запросами выглядит следующим образом.
1. Специалист 2го уровня поддержки (далее Автор) при обнаружении проблемы, которую
нельзя решить средствами имеющегося функционала в Системе, создаёт новый Запрос на
поддержку (ЗнП) в ИСП Jira РТК в соответствии с требованиями.
2. ЗнП создаётся в статусе «Открытый» и автоматически назначается на ответственного за
данную компоненту Исполнителя 3го уровня поддержки. Назначаемый автоматически
Исполнитель проводит первичный анализ проблемы и назначает ЗнП на непосредственного
Исполнителя (м.б. на себя).
3. Непосредственный Исполнитель берёт Запрос в работу (переводит в статус «В работе»),
указав ожидаемую дату окончания работ, и приступает к подготовке решения.
4. Если Исполнителю для дальнейшей работы над Запросом необходимо получить
дополнительную информацию, либо обратиться на 4й уровень, и работы не могут быть
продолжены, то Запрос снабжается соответствующим комментарием и переводится в статус,
отражающий, какого рода ожидание происходит.
5. Если Запрос был переведён Исполнителем в статус «Запрошена доп. информация», то
Автор запроса должен предоставить запрошенную информацию и вернуть Запрос в статус
«В работе».
6. Если решение по Запросу требует внесения изменений в Систему, Исполнитель
(разработчик), закончив разработку, собирает патч по Запросу, руководствуясь правилами,
описанными в Правилах разработки. Например:
 Если дефект, по которому собирается патч, относится к расширению, то назвать его надо
<at|rt>_<Коды расширений через подчеркивание>_<Код дефекта в Jira без
дефиса>_[<версия>]. Пример: at_XXGL005_XXGL007_SUPP520.zip. Перечисляются
все расширения, объекты которых присутствуют в патче, кроме общих расширений 000.
Патч по такому дефекту выкладывается в SVN, в папку расширения (первого по порядку
в перечислении). Для примера выше это: /appscode/trunk/GL/XXGL005.
 Если дефект не относится к расширению, то код расширения опускается. Пример:
at_SUPP520.zip. Собирается патч следующим образом: в папке /appscode/trunk/FIX/
создается подпапка по имени патча без префикса (SUPP520), внутри создается
минимальная структура папок для объектов (/sql и пр.), далее обычным способом
формируется патч.
Если патч не требуется, то далее к п.9.
7. Исполнитель (разработчик) тестирует установку патча сам на экземплярах DAYDEV или
HDAYDEV или назначает запрос на аналитика для тестирования (если он работает по
запросу), указав в комментарии строку успешной установки из таблицы XXRT_PATCHES.
Пример:
330 at_XXGL005_SUPP520 4-фев-2012 12:12:24 4-фев-2012 12:12:37 Y DAYDEV
r12a21.ks.rt.ru
8. Если Исполнителю нужно протестировать подготовленный патч на среде с ограниченным
доступом, то ЗнП переводится в статус «Установка на тестирование 3м уровнем» с
комментарием, который содержит имя экземпляра, на который требуется провести
установку, имя патча для установки и дополнительную информацию (например, требуется
пререквизит XXX). Факт успешного тестирования на экземпляре с ограниченным доступом,
отражается в Запросе комментарием «Протестировано на <Имя экземпляра>».
9. После того, как решение по Запросу было подготовлено, Запрос переводится
Исполнителем в статус «Выпуск патча» c комментарием, в котором либо даётся
исчерпывающий ответ на вопрос из описания проблемы, либо указывается имя патча,
который решает проблему, и даётся описание вносимых им изменений.
10. При переводе запроса в статус «Выпуск патча», происходит автоматическое назначение на
лидера компоненты, который или подтверждает правильность подготовленного решения
переводом запроса в статус «Исполнен», или возвращает запрос обратно в работу с
соответствующим комментарием.
11. После того, как Запрос был переведён в статус «Исполнен», Автор запроса должен
протестировать предложенное решение, запросив его установку на экземпляр с
ограниченным доступом и далее, если тестирование было признано успешным, установку на
промышленную среду. Установка патча запрашивается Автором переводом статуса в
«Установка на тестирование» и «Установка на продуктив» соответственно.
12. Статус «Установка на продуктив срочно» используется для срочной установки патча на
продуктив в рабочее время и является исключительной ситуацией, которой следует избегать.
Срочная установка может привести к техническим проблемам для других пользователей
вплоть до полной неработоспособности Системы. Запрос на срочную установку
сопровождается комментарием с обоснованием срочности, из которого должно быть
понятно, почему установка не может быть сделана после окончания рабочего дня.
13. Перевод запроса в статус «Установка на продуктив» (включая срочную установку)
автоматически назначает запрос на Администратора OEBS. Администраторы (DBA)
отслеживают такие назначения и берут их в работу, назначая на себя. После того, как
администратором были проведены все действия по установке патча, запрос переводится
обратно в статус «Исполнен» и автоматически подставляется предыдущий исполнитель.
14. Если результаты тестирования патча неоднозначны или в процессе тестирования появились
вопросы, требующие ответа от 3го уровня, то Запрос возвращается Автором в работу на 3й
уровень (переводом в статус «В работе»).
15. Когда патч был установлен на промышленную среду, после подтверждения от бизнеспользователей о решении проблемы и закрытия соответствующих запросов в САСП SM,
Запрос закрывается Автором переводом в статус «Закрыт с подтверждением».
Приложение № 3
к Техническим требованиям
Настоящее приложение представляет собой описание процедуры оказания услуг по доработке и
развитию функциональности системы управления объединенной компанией ОАО «Ростелеком» на
основе продуктов Oracle e-Business Suite R12.
1.
Ответственность за выполнение проектных задач при оказании услуг
Ответственность за выполнение проектных задач при оказании услуг будет распределена между
Исполнителем и Заказчиком следующим образом:
Задача
Исполнитель
Управление проектом
 Управление
границами
Управление
планом работ
Управление
Заказчик
Контроль статуса проекта
Согласование границ
проекта
качеством
Управление
рисками
Анализ требований
Анализ возможности
реализации новых
требований
 Проведение
анализа
Проектирование изменений
процессов или новых
процессов (при
необходимости) для
реализации требований
 Создание дизайна
новых процессов
или внесение
изменений в
процессы
Участие в обсуждении
возможных вариантов
реализации
Согласование
предлагаемых процессов
Создание доработок Oracle
R12
 Создание
дизайнов
доработок
Создание
доработок
Тестирование
доработок
Согласование дизайнов
доработок
Приемочное тестирование
доработок
Установка и настройка
системы
 Установка и
настройка
системы
Согласование настроек
системы
Приемочное тестирование
системы
Создание интерфейсов:
работы на стороне
существующих систем
Создание интерфейсов:
работы на стороне Oracle
R12
Проведение изменений в
организационной структуре
и процессах компании
 Формулировка и
предоставление
требований
Обсуждение требований
Определение приоритетов
среди сформулированных
требований
При необходимости,
уточнение требований
Согласование результатов
проведения анализа
Формулировка
требований к
выгружаемым
данным и
процедуре работы
интерфейса
Тестирование
интерфейса
 Согласование требований
Создание и тестирование
интерфейса
Приемочное тестирование
интерфейса
 Формулировка
требований к
выгружаемым
данным и
процедуре работы
интерфейса
Создание и
тестирование
интерфейса
Согласование требований
к выгружаемым данным и
процедуре работы
интерфейса
Приемочное тестирование
интерфейса
Оценка влияния
новых процессов
на компанию
 Проведение необходимых
организационных
изменений по переходу к
Методическая
помощь при
переходе на новые
решения
Создание документации
 Создание
документов AIM
Подготовка
инструкций
пользователей
Обновление
инструкций
пользователей
2.
новым процессам
Подготовка
распорядительных
документов по переходу к
новым процессам
 Согласование документов
AIM
Создание инструкций по
процессам, должностных
инструкций и т.п.
Процедуры оказания услуг
Управление проектом
1. Контроль за ходом выполнения проекта будет осуществлять Управляющий комитет, в
который войдут представители руководства Исполнителя и Заказчика. Управляющий
Комитет будет собираться не реже одного раза в месяц для осуществления оценки и
контроля за результатами проекта и принятия принципиальных решений, касающихся
проекта в целом.
2. Текущее управление проектом будет осуществляться двумя менеджерами –
Руководителем проекта от Исполнителя и Руководителем проекта от Заказчика. В случае
невозможности разрешения какой-либо проблемы на уровне руководителей проекта,
решение будет приниматься Управляющим комитетом.
3. Управление проектной командой будет производиться в соответствии с детальным
рабочим планом, ответственным за подготовку которого является Руководитель проекта
от Исполнителя. План оказания Услуг согласуется с Руководителем проекта от Заказчика.
Каждый член проектной команды должен оказывать услуги, в соответствии с этим
планом, и докладывать о ее результатах Руководителю проекта. При планировании
оказания услуг предполагается использовать программу Microsoft Project.
4. Помимо Управляющего Комитета раз в неделю будет проводиться статусная встреча
менеджеров проекта и главных бизнес-заказчиков в рамках Рабочей Группы по ERP для
обсуждения
плана
оказания
Услуг,
разбора
открытых
организационных,
функциональных или технических вопросов, которые не могут быть решены в рабочем
порядке. По результатам проектных заседаний будет составляться протокол встреч, и
рассылаться всем участникам.
5. Вся проектная документация будет храниться в библиотеке проекта.
6. Все ключевые документы (функциональные дизайны, результаты приемочного
тестирования и т.п.) должны визироваться ключевыми пользователями в бумажном виде.
Создание доработок
Принятие решений о доработках
1. При внедрении проекта по максимуму будет использоваться стандартная
функциональность Oracle e-Business Suite. При принятии решения о необходимости
создания той или иной доработки используются следующие критерии:

Качество и своевременность управленческой отчетности. Требования удобства
работы операционных пользователей системы имеют меньший приоритет.

Польза, обеспечиваемая доработкой, превышает затраты на создание программ и
их дальнейшее сопровождение.
2. В понятие доработки функциональности системы входит:

Изменение стандартных и создание новых отчетов

Изменение логики работы существующих программ пакетной обработки данных и
разработка новых программ в соответствии с бизнес требованиями

Изменение внешнего вида и логики существующих экранов и разработка новых
экранов в соответствии с бизнес требованиями.

Изменение существующих или добавление новых объектов базы данных в
соответствии с бизнес требованиями
3. Целью проектной команды является минимизация количества доработок, т.е.
максимальное использование стандартной функциональности системы.
Стандарты доработок
1. При создании доработок системы проектная группа будет строго следовать
стандартам разработки, рекомендуемым корпорацией Oracle e-Business Suite:

Oracle Applications Developer’s Guide (Release 12.1, Part Number E12897-02)

Oracle Applications User Interface Standards for Forms–Based Products (Release 12.1,
Part Number E12900-02)

Oracle Application Framework Personalization Guide (Release
E12646-02)
12.1, Part Number
2. Программный код доработок комментируется до уровня понимания назначения
используемых объектов, модулей, процедур.
3. Язык интерфейса пользователя – русский.
4. Документирование системы ведется на русском языке.
5. В процессе разработки используется система версионного контроля, предоставляемая
Заказчиком.
6. Для создания доработок Заказчик обеспечит отдельный экземпляр системы и
предоставит Исполнителю полный доступ к этому экземпляру
Гарантийная поддержка
Требования к Заказчику
1. Для эффективного взаимодействия в процессе решения дефектов Заказчик готов
предоставить и использовать автоматизированную систему регистрации и ведения
дефектов.
2. Для обработки дефектов с приоритетом 1 в режиме 24х7 Заказчик готов выделять
сотрудников в режиме работы команды поддержки Исполнителя.
3.
Общие проектные предположения
В данном разделе приведены проектные предположения, распространяющиеся на услуги,
оказываемые по Договору:
1. Во время оказания услуг ключевые пользователи Заказчика доступны для консультаций
на 20% времени.
2. Заказчик является обладателем лицензионных продуктов Oracle, с действующей
стандартной технической поддержки на продукты Oracle, предусматривающей
возможность формировать запросы к службе технической поддержки и получать
выходящие обновления программных продуктов.
3. С целью соблюдения требований по срокам оказания услуг, Заказчик должен обеспечить
целевые сроки по следующим показателям:

Принятие решения о реализации или выбор вариантов решения должно
происходить не более 5-и рабочих дней с момента официальной рассылки
документа.

Согласование функциональных дизайнов и документов по настройке должно
происходить не более 5-и рабочих дней с момента официальной рассылки. В
противном случае функциональный дизайн или документ по настройке считается
согласованным.
4. Заказчик готов обеспечить доступ к необходимым серверам, системам, базам данных в
режиме 24x7.
5. Заказчик предоставляет проектную библиотеку с разграничением прав доступа,
поддержкой контроля версий документов и системой резервного копирования
Заказчик:
Вице-Президент - Директор по информационным технологиям
ОАО «Ростелеком»
___________________ Садков Д.В.
Исполнитель:
Приложение № 2 к Договору
№________________ от «___» ________2014г.
Форма заказа.
Начало формы
Заказ на Услуги № __ от «__»________20__г. ("Заказ")
к договору №__ от «__»________20__г. ("Договор")
Исполнитель:
Адрес офиса Заказчика для передачи результата услуг: _________________________ ;
Контактное лицо _____________ (ФИО/ тел./e-mail).
№
Наименование
Услуг (в полном соответствии с указанными в ТЗ (по отдельным позициям))
1.
2.
3.
4.
5.
6.
7.
8.
* Менеджер проекта
- м.п.;
Архитектор проекта – а.п.;
Функциональный консультант - ф.п.;
Роль и ставка
специалистов
Исполнителя за
рабочий день*
Кол-во
специалисто
в
Трудоемкос
ть
Сумма,
с НДС
Дата
начал
а
оказа
ния
Услу
г
Дата
оконча
ния
оказан
ия
услуг
Технический консультант т.к..
Контактное лицо Исполнителя: _________________тел. ________________
Итого с
НДС:
Сумма
НДС
(18%):
Контактное лицо Заказчика по вопросам оплаты: ______________
0,00
0,00
E-mail ___________
Контактное лицо Заказчика по вопросам оформления Заказов: ______________
E-mail ___________
Исполнитель
Заказчик
ОАО "Ростелеком"
___________________________ /ФИО/должность
печать
___________________________ /ФИО/должность
печать
Окончание формы.
Форма согласована Сторонами:
Заказчик:
Вице-Президент - Директор по информационным технологиям
ОАО «Ростелеком»
___________________ Садков Д.В.
Исполнитель:
2
3
Код ОКВЭД
капитал
Уставный
Количество
руб.)
(тыс.
эмитированных
5
6
7
8
ОАО «Ростелеком»
___________________ Садков Д.В.
9
10
11
13
14
15
16
Заказчик:
Вице-Президент - Директор по информационным технологиям
Срок действия
договора
Иные
существенные
условия
№
Сумма в валюте
договора
12
Валюта договора
с
1
7
п
о
1
8
19
20
21
от Исполнителя:
Должность
_____________ФИО
М.П.
Окончание формы
С формой согласны:
Исполнитель:
22
23
24
(наименование организации, представляющей информацию)
3
4
Договор (реквизиты, предмет,
Информация о цепочке собственников контрагента, включая
цена, срок действия и иные
бенефициаров (в том числе, конечных)
существенные условия)
25
26
27
акций (для
акционерных
Серия и номер
регистрации
Адрес
обществ)
документа,
удостоверяющего
личность
Доля в уставном
для
(обязательно
Количество
капиталелица)
физического
акций(для
Номинальная
акционерных
акций
стоимость
обществ)
акционерных
(для
Руководитель /
(руб.) о
обществ)
Информация
/ акционер
участник
подтверждающих
/ бенефициар
документах
(наименование, реквизиты
и т.д.)
Форма
собственности
Наименование /
ФИО
капитал
Уставный
Количество
(тыс. руб.)
эмитированных
ОГРН
Российский/
Иностранный
Физическое
лицо/Юридич
еское лицо
ИНН
Наименование контрагента (ИНН, вид
деятельности)
Предмет договора
2
Дата заключения
договора
1
акций (для
Имя,
Фамилия,
акционерных
номер
и
Серия
Отчество
обществ)
документа,
руководителя
удостоверяющего
личность
№ договора
руководителя
Наименование
4
Форма
собственности
ОГРН
ИНН
1
Российский/
Иностранный
№ п/п
Приложение № 3 к Договору
№________________ от «___» ________2014г.
Форма предоставления информации об изменениях в цепочке собственников контрагента, включая бенефициаров
(в том числе, конечных).
Начало формы
28
29
30
31
32
33
5
34
35
Приложение № 4 к Договору
№________________ от «___» ________2014г.
ПЕРЕЧЕНЬ УСЛУГ
№
Наименование услуги
1
Услуги по проведению обследования, анализу, разработке новых бизнеспроцессов, анализу эффективности существующих и выработке предложений по
их оптимизации
2
Услуги по проектированию новых и модификации существующих экранных
и/или отчетных форм ERP системы на базе Oracle E-Business Suite R12,
интеграции с внешними системами
3
Услуги по разработке новых и модификации существующих экранных и/или
отчетных форм Систем R12, интеграции с внешними системами
4
Услуги по администрированию, настройке, управлению, поддержанию
архитектурной целостности ERP системы на базе Oracle E-Business Suite R12
5
Услуги по разработке пользовательской документации (инструкций конечного
пользователя ERP системы на базе Oracle E-Business Suite) и методических
указаний по работе с ERP системой
6
Услуги по проведению тестирования, как отдельных компонентов Систем R12,
так и по проведению интеграционного тестирование нескольких компонентов
ERP системы на базе Oracle E-Business Suite R12
7
Услуги по конвертации данных в ERP систему из замещаемых систем
8
Услуги по обучению и патронажу конечных пользователей на этапе запуска
системы в подразделениях компании
Предельная трудоемкость услуг,
человеко-дней