Регламент работы службы технической поддержки

Версия 2.0
Статус: Принят работу

2020

Содержание
1. Общие положения .............................................................................................................. 4
2.

Порядок приема, передачи и обработки обращений ....................................................... 4

3.

Сроки обработки обращений ............................................................................................. 6

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

Регламент работы службы технической поддержки.

Страница 2 из 14

Термины и сокращения
Техническая поддержка программного продукта - непрерывный процесс, который
охватывает весь комплекс мероприятий по поддержке и сопровождению программных
продуктов, которые сданы в эксплуатацию Пользователям;
Заявка (тикет) – письменное (при необходимости, согласно п. 2.4., телефонное вн.
1199 / 1200) обращение Заявителя в службу технической поддержки Е100 через адрес
it@e100.pro, support@e100.eu, support@e100pro.com. Содержит в себе описание
возникшей у Заявителя проблемы / запроса, а также данные, необходимые для
определения способа решения проблемы. Каждой заявке, попадающей в систему Zoho,
автоматически присваивается уникальный номер, который направляется Заявителю для
возможности дальнейшего отслеживания жизненного цикла запроса;
Zoho — система обработки заявок, поступающих от Заявителей в службу технической
поддержки Е100. Система служит для классификации всех заявок, их учета,
распределения, а также для контроля исполнения запросов;
Жизненный цикл заявки (тикета) – движение заявки (тикета) в рамках ИТ –
департамента от момента его регистрации (возникновения) до момента закрытия
(решения) в системе Zoho службой технической поддержки. Заявки (тикеты) могут
исполняться как сотрудниками технической поддержки, так и распределяться на
сотрудников смежных отделов (команды управления разработки, ОСА, РМО);
Техническая поддержка 2й линии – подразделение ИТ - департамента, обрабатывающее
заявки (тикеты) от Заявителей в системе Zoho;
Команды управления разработки – подразделения ИТ – департамента, которые
занимаются разработкой, доработкой и тестированием программных продуктов,
исправлением ошибок, а также выкаткой обновлений;
ОСА – отдел системного администрирования, подразделение ИТ - департамента, которое
сопровождает все инфраструктурные запросы;
РМО – Project Management Office, подразделение ИТ - департамента, которое отвечает за
управление проектами и запросами на изменение (CR);
Инцидент – любое событие, которое не является частью стандартных операций
сервиса, вызывает или может вызвать прерывание обслуживания или снижение
качества сервиса.
JIRA – система управления проектами, в которую Служба технической поддержки заводит
задачи для команд управления разработки;
SLA - соглашение об уровне предоставления услуги: формальный договор между
Заказчиком услуги (Заявителем) и ИТ – департаментом, содержащий описание услуги,
права и обязанности сторон, а также согласованный уровень качества предоставляемой
услуги.
Типы запросов:
•

Запрос на обслуживание – запрос по инфраструктуре, на выдачу прав, доступов, по
закупкам оборудования;

•

Bug – ошибка в программном продукте, вследствие которой продукт ведет себя
непредвиденно (неверно);

•

Consulting – запрос на консультирование по работе программного продукта;

Регламент работы службы технической поддержки.

Страница 3 из 14

•

Change Data – запрос на изменение, добавление, удаление, обновление данных
в программном продукте;

•

Change Request – запрос на изменение программного продукта в рамках его
улучшения или доработки;

Общие положения

1.

1.1. Настоящий Регламент устанавливает порядок оказания услуг по технической
поддержке программных продуктов и ИТ-инфраструктуры Службой технической
поддержки Компании ООО «Евразийская процессинговая компания»;
1.2. Техническая поддержка доступна пользователям программных продуктов и
ИТинфраструктуры группы Компаний, имеющих договор Технической Поддержки с
ООО «Евразийская процессинговая компания», сотрудникам ООО «Евразийская
процессинговая компания», а также Клиентам и Поставщикам Компании ООО
«Евразийская процессинговая компания» согласно действующего между ними
Договора;
1.3. В рамках технической поддержки решаются вопросы, определённые данным
регламентом, согласно установленным уровням обслуживания (SLA - Service Level
Agreement).
2. Порядок приема, передачи и обработки обращений
2.1. Пользователи группы Компаний, имеющих договор Технической поддержки с ООО
«Евразийская процессинговая компания», обращаются в Службу технической
поддержки путем направления заявки (тикета) посредством электронной почты на
адрес: it@e100.pro . Партнеры Н2Н направляют обращения на адрес support@e100.eu,
клиенты е100pro направляют обращения на адрес support@e100pro.com ;
2.2. Служба технической поддержки обрабатывает обращения, связанные с
возникновением инцидентов, запросами на обслуживание, изменением данных и
консультациями;
2.3. Обращения в Службу технической поддержки принимаются с внешних и
внутренних адресов;
2.4. Обращения, поступившие в Службу технической поддержки иными способами
(Skype, телефонный звонок и иные, не указанные в п. 2.1.) считаются ненадлежаще
оформленными и в их исполнении может быть отказано, за исключением случаев,
когда у Заявителя нет возможности воспользоваться почтой, а также если требуется
разблокировать учетную запись Заявителя либо предоставить пароль от почты; 2.5. В
обращении должны быть точно и грамотно сформулированы вопросы, требующие
разъяснения, и описаны проблемы, требующие решения. Для наиболее оперативного
решения вопросов, обращения в Службу технической поддержки должны содержать
следующую информацию:
•

Контактные данные (ФИО сотрудника, регион, название фирмы, отдел,
внутренний номер телефона);

Регламент работы службы технической поддержки.

Страница 5 из 16

•
•

•

•
•
•

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

В заявке рекомендуется использовать терминологию, принятую в программном
продукте, в котором возникла проблема.
В случае ненадлежаще оформленного обращения (отсутствие достаточной информации
для анализа, решения и обратной связи) Заявителю Службой технической поддержки
будет отправлен запрос на уточнение/дополнение данных. В случае не предоставления
Заявителем ответа на уточняющий запрос в течение 2 рабочих дней с момента его
отправки, в исполнении заявки Службой технической поддержки будет отказано
(обращение будет считаться закрытым);
2.6.

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

2.7.

При подаче заявки необходимо придерживаться правила – одному запросу
(тикету)
соответствует
один
инцидент
(переписка
по
одному
инциденту/проблеме должна вестись строго в рамках одного обращения);

2.8.

Переписка должна вестись в рамках делового этикета. Не допускаются грубые
высказывания и оскорбления;

2.9.

Служба технической поддержки является только прямым адресатом, постановка
адреса it@e100.pro в копию не допускается, подобные заявки (тикеты) не будут
рассмотрены и обработаны;

2.10. Не допускается пересылать на адрес Службы технической поддержки
it@e100.pro цепочки писем. Необходимо направить только описание инцидента
согласно пп. 2.5, 2.7 отдельной заявкой (тикетом);
2.11. При приеме заявки Службой технической поддержки ответственный специалист
обязан провести оценку заявки на допустимость ее исполнения в соответствии с
правилами общей, информационной и / или финансовой безопасности Компании.
В случае возникновения подозрения, что исполнение заявки может привести к
нарушению правил общей, информационной и/ или финансовой безопасности
Регламент работы службы технической поддержки.

Страница 6 из 16

Компании либо нарушению деятельности ПО и информационных систем
(например, возможность отпуска клиентам товаров и предоставление услуг,
корректного отображения балансов клиентов) специалист технической
поддержки обязан запросить консультацию у своего непосредственного
руководителя. При необходимости, консультация может быть запрошена у
руководителей других отделов и Службы Безопасности.
2.12. Суть заявки (тикета) должна содержать в себе запрос на оказание ИТ – услуги и
должна относится к рамкам деятельности ИТ – департамента;
2.13. Решение заявки предоставляется Заявителю в письменном виде;
2.14. Заявитель, в случае несогласия с предоставленным решением заявки, в течение 1
– го рабочего дня может возобновить работу Службы технической поддержки по
данной заявке;
2.15. В случае отсутствия замечаний со стороны Заявителя по предоставленному
решению заявки в течение 1 –го рабочего дня, Заявителю направляется
автоматическое уведомление о закрытии заявки (тикета);
2.16. После закрытия заявки Заявителю автоматически направляется опрос по
качеству исполнения заявки (тикета) и оказанной услуги;
3. Сроки обработки обращений
3.1. График работы Службы технической поддержки:
9:00 – 22:00 в рабочие дни
10:00 – 22:00 в выходные и праздничные дни; 3.2.
Классификация и сроки обработки обращений:
Обращения в Службу технической поддержки классифицируются по типу обращения и
сервису (программному продукту).
3.2.1. Поступающие в Службу технической поддержки обращения присваивается
классифицируются по типам:
•
•
•
•
•

Bug;
Change Data;
Consulting;
Запрос на обслуживание;
CR;

3.2.2. Поступающим обращениям присваиваются SLA и приоритет (критичность);
Детализация сроков реакции и сроков решения в разрезе уровней техподдержки
представлена в Приложении 2 к Регламенту.
Важно! При установке SLA в тикете Заявителю отправляется автоматическое
информирование о предполагаемых сроках решения;
Важно! При передаче заявки в другой отдел (отдел системного администрирования,
команды разработки) также будет отправлено
информирование Заявителю;
Важно! Заявки (тикеты), в которых требуется согласование на выдачу прав,
доступов или закупка оборудования, направляются на лицо, принимающее решение с
формулировкой, что согласование необходимо предоставить в течение 2-х рабочих
Регламент работы службы технической поддержки.

Страница 7 из 16

дней, в противном случае заявка будет закрыта в связи с невозможностью ее решения.
В копию ставится Заявитель.
Важно! Задачи на команды разработки, имеющие приоритет minor и не оказывающие
влияния на рабочие процессы заявителя (их качество или скорость), оцениваются
командами разработки в течение 5 рабочих дней на предмет реализации. Если такая заявка
не будет реализована в ближайшее время командами разработки, то тикет будет закрыт и
заявителю будет направлено соответствующее уведомление.
3.2.3. Приоритеты исполнения обращений
Приоритеты исполнения выставляются на основании информации, предоставленной
Заявителем;
Следующие приоритеты по сервисам имеют статус «критичный сервис» и
предполагают сокращенный срок решения заявки:
1. Выставление (в период выставления, срок решения 3 часа):
1.1
1.2

Отказ ПО биллинга (FaqsPrinter, FQLoader, ICC, DOP, POST, TE, Supplier,
EM, LP, PriceCommander, CRM 2.0);
Любые проблемы, которые задерживают процесс выставления согласно
графика;

2. Функциональность процессинга E100 (24h / 7 дней, срок решения 3 часа):
2.1

2.2

2.3

Авторизация: (3х и более пользователей в течение 1 часа):
2.1.1 Авторизация любых карт и любых типов запросов на терминалах
E100;
2.1.2 Отказ более 10 терминалов Е100 в течение часа;
2.1.3 Авторизация через виртуальный терминал с сайта;
2.1.4 Превышение лимита (совершение кражи) в текущий момент
времени;
Стоп-листы:
2.2.1 StopListManager: управление стопами;
2.2.2 Выгрузка стоп-листов партнерам;
Сайт HotLine:
2.3.1 Проведение ТПТ;
2.3.2 Разблокировка карт;
2.3.3 Проверка лимитов;

3. Авторизация межэмитентка и партнеры (24h / 7 дней, срок решения 3 часа):
3.1

Авторизация карт E100 на партнерских сетях (3х и более Пользователей в
течение 1го часа);

4. Инфраструктура (рабочее время / 5 дней):
4.1
4.2

Отказ телефонии у групп: топ - менеджеры, продажи, ДОК;
Отказ почты у групп: топ - менеджеры, продажи, ДОК;

Регламент работы службы технической поддержки.

Страница 8 из 16

5. СМС оповещение процессинга Е100 (24h / 7дней):
5.1

SMS об активации клиента;

6. Обмен информацией с налоговыми органами (Испания и др., согласно графика
обмена данными):
6.1
6.2

Некорректно отработала выгрузка XML из ICC;
Подразделение биллинг:
6.2.1 некорректный прием XML Испания в 1С E100IT; 6.3 Подразделение
бухгалтерия региона:
6.3.1 Некорректная выгрузка данных по фактурам наших клиентов в CSV
файл;
6.3.2 Некорректная выгрузка данных по фактурам поставщиков в CSV файл;

7. ЛК (24h / 7дней): 7.1 "Баланс": размер кредита, баланс;
7.2 "Баланс": детализация;
7.3 "Транзакции": значения в суммах;
7.4 "Транзакции": отображение транзакций, экспорт;
7.5 "Карты": фильтры (создание, редактирование, удаление);
7.6 "Фактуры" - работоспособность всех функций (отображение, скачивание,
поиск, просмотр приложений к счету, архив);
7.7 "АЗС и цены": переход на АЗС локатор;
8. МЛК (24h / 7дней):
8.1
8.2

Полный отказ работы в течение 15 минут;
Аналогичные ошибки (включая некорректные данные) у 3х и более
клиентов в течение 15 мин.;

9. АЗС локатор (рабочее время / 5дней):
9.1

Полный отказ работы в течение 15 минут;

10. База ICC (24h / 7дней):
10.1 Загрузка оплат в ICC (рабочее время / 5дней);
10.2 Невозможность поставить аванс 3м и более клиентам/агентам в течение 15
мин;
10.3 Отказ клиент – банка;
10.4 Ошибка разнесения / передачи выписок;
10.5 Невозможность отправки платежей бухгалтерией;
11. agents.e100.eu (24h / 7дней, срок решения 3 часа):
Регламент работы службы технической поддержки.

Страница 9 из 16

11.1 установка размера лимита агентом отдельным клиентам;
11.2 постановка аванса на агента через reg.e100.eu;
11.3 при исчерпании лимита агента - блокировка и разблокировка клиентов
(только после реализации проекта);
11.4 вход из кабинета агента в отдельного клиента;
11.5 правильное отображение всех клиентов в кабинете;
11.6 вход в кабинет агента;
11.7 правильное отображение и расчет общего лимита агента;
12. E100Pro (24h / 7дней, срок решения 3 часа):
12.1 Онлайн авторизация транзакций;
12.2 Работа схемы ценообразования на аналитическом сервере и корректный
расчёт;
12.3 ЛК администратора /менеджера: добавление оплат;
12.4 ЛК администратора /менеджера: блокировка карт /клиентов;
12.5 RestAPI (доступность и работоспособность всех методов);
12.6 1С методы интеграции;
12.7 ЛК администратора /менеджера: заведение клиентов;
12.8 ЛК Клиента: баланс;
12.9 ЛК администратора /менеджера: получение отчётов;
12.10 ЛК администратора /менеджера: изменение фильтров;
13. Инциденты информационной безопасности (24h / 7дней, срок решения 3 часа):
13.1 Разглашение либо угроза разглашения конфиденциальной информации
(включая подозрение);
13.2 Несанкционированный доступ к конфиденциальной информации со
стороны лиц, которые не имеют согласованного доступа к этой
информации
(включая подозрение);
13.3 Превышение полномочий учетной записи, получение более высоких
привилегий, чем позволяет согласованный доступ, либо получение доступа
к большему количеству информации (включая подозрение);
13.4 Любая компрометация систем. Например, компрометация учетных записей
или паролей (включая подозрение);
13.5 Вирусная атака или вирусное заражение (включая подозрение);
13.6 Внешнее или внутреннее сканирование информационных систем, DDoS
атака или брутфорс, атака на любую из ИС (включая подозрение);
13.7 Нарушение правил использования персональных данных, их
компрометация или угроза разглашения (включая подозрение);
Примечания:
1. Рабочее время – время с 08.00 по 20.00 МСК в рабочие дни;
2. Рабочий день – день, когда официально работает хотя бы один из офисов Е100
(включая переносы).
Регламент работы службы технической поддержки.

Страница 10 из 16

3.

4.
5.

6.

Важно!
Заявки из вышеуказанных критичных сервисов должны содержать в теме письма тег
[critical] или [критично]. Не допускается использование указанных тегов в
некритичных заявках;
Критичные заявки рекомендуется дублировать звонком на дежурные номера Службы
технической поддержки;
Поднять приоритет заявки, если она не входит в вышеперечисленные критичные
сервисы, могут только руководители подразделений и руководители отделов путем
согласования с руководителем ИТ – департамента либо с его заместителем;
Если в теме письма указан тег [critical] или [критично], однако заявка не является
критичной согласно списку критичных сервисов, который утвержден руководством
Холдинга, а также приоритет заявки не подтвержден руководителем отдела с
обоснованием, то такой заявке присваивается приоритет major или minor, заявка
решается в рамках установленных сроков SLA. Заявителю направляется список
согласованных критичных сервисов в шаблоне ответа для ознакомления и
дальнейшего применения при формировании заявок.

7. Порядок взаимодействия отдела технической поддержки со смежными
отделами при обработке поступивших обращений
4.1. Участвующие субъекты:
1. Заявитель;
2.
3.
4.
5.
6.

Служба технической поддержки (2-й уровень техподдержки);
Команды управления разработки;
Отдел системного администрирования;
Служба безопасности;
Отдел аналитики (финансовый департамент);

Регламент работы службы технической поддержки.

Страница 11 из 16

7. Отделы, не входящие в состав ИТ – департамента;
4.2. Порядок взаимодействия между отделами при обработке поступивших заявок
в Службу технической поддержки
4.2.1. Обработка заявок на доработку / разработку программных продуктов от
Заявителей (взаимодействие с РМО):
1. Все заявки на открытие нового проекта оформляются письмом с помощью брифа
проекта (приложение 1) на руководителя РМО;
2. Заявка, в которой содержится запрос на доработку (изменение) программного
продукта, на реализацию которого потребуется менее 120 чел / часов,
квалифицируется в CR;
3. Сотрудник технической поддержки высылает Заявителю форму заполнения для
CR и список лиц, уполномоченных выставлять приоритеты для очередей CR;
4. После получения заполненного брифа CR, а также приоритета задачи от
руководителя направления, CR передается сотрудником технической поддержки
в РМО;
5. Очереди CR контролирует РМО;
6. Коммуникации по CR, которые были приняты в работу, осуществляет РМО;
4.2.2. Порядок взаимодействия между отделом технической поддержки и отделом
системного администрирования:
1. Прием (очередь, приоритет, SLA) и первичную аналитику по тикету проводит
сотрудник тех. поддержки. При этом сотрудник тех. поддержки собирает доп.
информацию по тикету, если в этом есть необходимость;
2. Тикет с аналитикой сотрудник тех. поддержки назначает на ответственного
сотрудника отдела системного администрирования;
3. Сотрудник ОСА проводит аналитику тикета и выполняет следующие действия:
4. Сотрудник ОСА Отправляет тикет на сотрудника тех. поддержки с перечнем
информации, которую нужно запросить у заявителя в форме, которую можно
отправить заявителю без корректировок;
5. Сотрудник Службы технической поддержки приступает к обработке тикета на
основании полученной информации;
6. Сотрудник отдела СА после получения доп. информации от отдела тех.
поддержки работает по тикету - выполняет требуемые работы, при
необходимости самостоятельно запрашивает доп. информацию;
7. После выполнения работы сотрудник отдела СА самостоятельно запрашивает
обратную связь у пользователя. Обратную связь сотрудник отдела СА
запрашивает по доступным каналам связи - телефон, скайп, Zoho;
8. В случае отсутствия обратной связи в течение 1-го рабочего дня сотрудник
отдела СА назначает тикет на сотрудников тех. поддержки с пометкой "Обратная
связь не получена";
9. При положительной обратной связи сотрудник отдела СА возвращает тикет на
сотрудника тех. поддержки с обязательной пометкой: "Получена положительная

Регламент работы службы технической поддержки.

Страница 12 из 16

обратная связь. Также дается описание проведенных работ: (например, Доступ
предоставлен, исправлена проблема с отправкой почты и т.д.)";
10. Сотрудник службы технической поддержки закрывает тикет;
11. В случае, если заявитель возобновил тикет с пометкой "Не исправлено. Доступа
нет", а по обратной связи сотрудник ОСА написал, что получил положительный
ответ - сотрудник тех. поддержки эскалирует тикет сразу на руководителя отдела
системного администрирования.
4.2.3. Порядок взаимодействия между отделом технической поддержки и
управлением разработки:
1. Заявка классифицируется как Bug, Change Data, Consulting;
2. В случае, если техническая поддержка самостоятельно не может решить заявку,
то заводится задача в Jira на профильную команду разработки;
3. Сотрудник команды разработки, решив задачу, закрывает ее в Jira и информирует
техническую поддержку по доступным каналам связи (телефон, скайп, почта,
Zoho) о решении задачи;
4. В случае, если сотрудник команды разработки приходит к выводу, что задача не
может быть решена в срок по каким – то причинам, он информирует об этом
службу технической поддержки по доступным каналам связи;
4.2.4. Порядок взаимодействия между отделом технической поддержки и
отделом аналитики (финансовый департамент):
1. При получении тикета на выгрузку аналитических данных, техническая
поддержка производит проверку списка полей, по которым данные может
выгрузить отдел аналитики;
2. Если в списке полей будут те поля, которые запрашивает пользователь,
то техническая поддержка сообщает пользователю, что ему необходимо
обратиться в отдел аналитики по адресу analytics-support@epc-it.by ;
3. Тикет в технической поддержке закрывается;
4. Если тех. поддержка не может определенно идентифицировать, может ли
отдел аналитики выгрузить запрашиваемые данные, то техническая
поддержка обращается в отдел аналитики по адресу analytics-support@epcit.by за уточнением самостоятельно, и, далее при необходимости, заводит
задачу на команду разработки.

4.3.

Ответственность участвующих субъектов:

Заявитель, при подаче заявки в Службу технической поддержки, обязан следовать
правилам подачи заявок, указанным в п.2.5 настоящего регламента.
Служба технической поддержки несет ответственность за:
•

Своевременное реагирование на заявки, поступающие от заявителей;

•

Уведомление заявителей о принятии отправленных ими заявок в работу;

•

Своевременную передачу заявок для решения в команды управления разработки;
Своевременную
передачу
заявок
для решения
в

•

отдел системного администрирования;
Регламент работы службы технической поддержки.

Страница 13 из 16

•
•
•

Отслеживание сроков исполнения заявок;
Уведомление заявителей об исполнении заявок, отправленных ими в Службу
технической поддержки;
Постоянное накопление и обновление базы знаний по решению заявок,
поступающих от заявителей, в том числе решенных другими исполнителями
(отделами);

Управление разработки несет ответственность за:
•

Своевременное реагирование на заявки, относящиеся
специалистов управления разработки (задачи в Jira);

•

Решение задач, переданных в команды управления разработки;

•

Соблюдение установленных сроков реагирования и решения задач;

•

Предоставление информации сотрудникам отдела технической поддержки о
исполнении (ходе исполнения) заявки;
Предоставление информации о способе решения проблемы Службе технической
поддержки;
Предоставление необходимых инструментов для решения часто повторяющихся
проблем (заявок) Службе технической поддержки;

•
•

•

к

компетенции

Создание вспомогательной технической документации по решению задач; Отдел
системного администрирования несет ответственность за:

•
•

Соблюдение установленных сроков реагирования и решения запросов на
обслуживание, переданных Службой технической поддержки;
Исполнение запросов на обслуживание заявителей, проверка корректности
проделанной работы (получение обратной связи от заявителя) и уведомление
Службы технической поддержки об окончании произведенных работ;
Приложение 1

Бриф запроса на изменение
(Change Request) \
Wniosek o zmianę systemu

Версия\
Wersja

1.0

Дата\Data

Название запроса\ Nazwa wniosku
Заявитель\ Wnioskodawca
Руководитель подразделения\
Kierownik działu
К которому относится заявитель \ Do którego należy
wnioskodawca

Исходная ситуация, предпосылки,
проблемы\ Początkowa sytuacja,
warunki wstępne, problemy
Какую проблему нужно решить? \ Jakie są problemy do
rozwiązania?

Цель\ Cel

Регламент работы службы технической поддержки.

Страница 14 из 16

Измеримая цель выполнения запроса\ Wymierny cel
zmiany

Желаемый срок\ Pożądany okres
Когда вы ожидаете получить результат? Как была
определена эта дата? \ Kiedy spodziewasz się uzyskać
wynik w projekcie? Jak została ustalona data?

Бизнес-стимул\ Zachęte biznesowe
Какой полезный эффект получит компания от
реализации данного запроса? Выберите один или
несколько бизнес-стимулов из таблицы и
рассчитайте экономический эффект: \ Jaki jest skutek od
realizacji tego projektu? Wybierz jedną lub więcej zachęt
biznesowych z tabeli:

Влияние на бизнес компании 

1-ый год, $
1 rok, $

Wpływ na działalność firmy
Финансовое / Finansowe

Увеличение выручки / Wzrost
przychodów

Снижение затрат / Zmniejszenie kosztów

2-ой год, $
2 rok, $

Комментарии
Komentarze




Позиционирование / Pozycjonowanie
Увеличение лояльности клиентов /



Zwiększenie lojalności klientów

Повышение уровня информационной
безопасности / Zwiększenie poziomu



bezpieczeństwa informacji

Минимизация рисков / Minimalizacja
ryzyka

Повышение надежности / Zwiększyć
niezawodność systemu
Стандартизация / Standaryzacja

Прочее (пожалуйста, заполните поле
комментарий) / Inne (proszę o wypełnienie






pola komentarza

Ожидаемые результаты\
Oczekiwane rezultaty
Какой инструмент/функционал должен
появиться в результате выполнения запроса?
\Jakie narzędzie / funkcjonalność powinny pojawić
się w wyniku realizacji wniosku?

Рабочая группа\Grupa robocza
К кому еще можно обратиться за уточнениями в
случае отсутствия заявителя? \ Do kogo można
się zwrócić w celu sprecyzowania w przypadku
braku wnioskodawcy?

Пользователи\ Użytkownicy
Кто пользуется результатом доработки
системы? \ Kto korzysta z wyników zmiany?

Регламент работы службы технической поддержки.

Страница 15 из 16

Риски и предположения\
Zagrożenia i propozycje
Что может пойти не так, что необходимо учесть?
\ Co może pójść nie tak, co trzeba wziąć pod
uwagę?

Регламент работы службы технической поддержки.

Страница 16 из 16