Bankir.Ru
9 декабря, пятница 07:04

Объявление

Свернуть
Пока нет объявлений.

Пути организации единого IT Call центра и качественное обслуживание USERов

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Пути организации единого IT Call центра и качественное обслуживание USERов

    Сложная проблема интеграции всех отделов IT департамента в единое целое с целью решения задач качественного обслуживания пользователей.
    Идея не нова: пользователь имеет только один тел. номер поддержки, не зависимо от того, что у него за вопрос... будь то HARD или SOFT, картридж или т.п.
    Известные программные решения от HP Open View или Remedy не позволяют до конца решить вопрос интеграции отделов для решения вопроса, с которым обратился пользователь, но позволяют адаптировать SOFT под клиента.
    Однако, адаптация софта под неорганизованную структуру заказчика не есть постановка четко проработанного ноу хау у клиента. Интеграторы предлагают обследование и адаптацию системы с уже существующими т.е. заведомо не рациональными.
    Есть ли у кого опыт подобноц организационной работы?
    Очень интересен опыт пилота от первоисточника Внешэконома. Заранее спасибо.

  • #2
    2 ASF

    Для меня не совсем очевидна цель, определенная Вами для IT-департамента. По приведенным Вами примерам:
    - проблем с HARD не должно быть по определению - их нужно предупреждать, а не устранять (ну, это раньше называлось планово-предупредительными ремонтами - придумали ещё в СССР, а потом и по всему миру разошлось). Унификация рабочих мест, отлаженные конфигурации - сотрудник банка дожен работать!
    - то же относится и к картриджам и т.п. - к моменту печати картридж должен быть готов. Обеспечивается тем, что во внеоперационное время сотрудник из службы поддержки живо бегает по принтерам и отслеживает их готовность. Опять-таки - сотрудник банка должен работать!
    - проблемы с СОФТом тоже должны отсутствовать. Почему? Потому что:
    а) бизнес-процессы в банке стабильны и непротиворечиво отражены в информационной системе;
    б) сотрудники банка обучены работе с системным программным обеспечением, офисным ПО;
    в) сотрудники банка обучены работе с прикладными информационными системами (АБС, система документооборота и т.д) в рамках своих полномочий;
    г) сотрудники банка сдали квалификационные тесты (или сдали экзамены, получили разрешение на допуск, получили сертификат - можно назвать по разному), подтверждающие их навыки работы с ИС.
    Ещё раз - аварийные и критические ситуации - это исключение, а не правило, и их устранение - исключительная работа IT-подразделения, а не штатная.

    Думаю, что более корректно было бы говорить о качественном _сопровождении_ работы пользователей (сотрудников банка) - но это лишь одна из задач IT-департамента, решаемая совместно с учебным подразделением (которое может существовать в рамках банка, или вне его), а также основными службами банка при организации бизнес-процессов.

    Давайте ещё попробуем определиться с целями IT-департамента, и решаемыми задачами.


    С уважением, Aha

    Комментарий


    • #3
      Абсолютно правильно пишет Aha
      Да пребудет с Тобою Великая Сила! ©

      Комментарий


      • #4
        Aha
        Практически верно, но...
        то же относится и к картриджам и т.п. - к моменту печати картридж должен быть готов. Обеспечивается тем, что во внеоперационное время сотрудник из службы поддержки живо бегает по принтерам и отслеживает их готовность. Опять-таки - сотрудник банка должен работать!

        Например на штат сотрудников эдак в 1000 человек используется.. ну в лучшем случае 10 принтеров.. при этом 1000 человек занимают не слабую площадь и что прикажите выдавать ролики техслужбе? Опять же это большие принтера, на маленьких (читай локальных), ну очень тяжело определить остаток порошка/ качество ленты, опять же существуют режимные помещения. в которые есть доступ только в рабочее время, поэтому как мне кажется, заказ таких типов расходников всё же должен выноситься в HelpDesk.

        Вопрос с работой железа, тоже открыт.. даж унифицированные рабочие места и типовые конфигурации не спасают от поломок, и вот тут то и появляется заявка в helpdesk, а уж мальчик(девочка) прибегает оценивает поломку и меняет железку, ну и так как всё стандартно, то займёт этот процесс 10 минут..[/QUOTE]
        С уважением

        SunDog

        Комментарий


        • #5
          Абсолютно правильно пишет Aha

          Хотел бы я знать, существуют ли в природе такие банки...

          Комментарий


          • #6
            SunDog Например на штат сотрудников эдак в 1000 человек Э-э-э, Батенька, да Вам при таком штате без ИТ-Консалтинга не обойтись никак. Это не "угроза", и не "предложение", просто - констатация факта...

            Pif Хотел бы я знать, существуют ли в природе такие банки... Существуют. Можно Ваш таким сделать...
            Да пребудет с Тобою Великая Сила! ©

            Комментарий


            • #7
              К_Маркелов
              Подскажите пож. в каком банке такой идеальный порядок и организация?
              Может быть буржуинский?

              Комментарий


              • #8
                ASF Почему - буржуинский??? Потенциально - ВАШ БАНК! Хотите конкретику - welcome в Би- или Е- мэйл, т.к. открытая реклама здесь запрещена...
                Да пребудет с Тобою Великая Сила! ©

                Комментарий


                • #9
                  К_Маркелов да! Запрещена! Но мы тут все свои... Да и что рекламой называть - пральную организацию?
                  Подавая сигналы в рог будь всегда справедлив, но строг. ©

                  Комментарий


                  • #10
                    2 ASF & Pif

                    Такие банки есть! Причем российские и даже не-московские
                    Рано или поздно к подобному подходу (описанному выше) приходят все организации (а не только банки) ориентированные на _стабильную_ работу. Может быть, я слегка идеализирую виденное мной на протяжении нескольких лет, но тем не менее - с каждым годом это становилось всё более похоже на реальность. Жизнь заставляет, и учёба на своих же ошибках
                    Да, безусловно, всё в этом миру ломается (и Hard, и Soft), но всё таки более плодотворно ориентироваться на предупрежедение критических ситуаций, чем на их устранение. Может быть, на начальном этапе внедрения подобного подхода потребуются относительно большИе усилия (финансовые, организационные). Также гарантирую, что введение подобного подхода на начальном этапе объективно будет неэффективным - потому что она изначально будет существовать в среде, не рассчитанной на подобную работу (пока отладите технику, пока до конца обучите людей). Но в перспективе, после окончания переходного этапа, работа будет более стабильной - а про IT департамент вообще забудут (кстати, один из больших минусов предлагаемого подхода).

                    Тем не менее, еща раз напоминаю, что _сопровождение_ работы сотрудников банка - это лишь одна задача IT департамента из многих.

                    С уважением, Aha

                    Комментарий


                    • #11
                      Aha
                      Ну хоть несколько банков назовите - интересно же!

                      Комментарий


                      • #12
                        Aha

                        Такие банки есть! Причем российские и даже не-московские
                        Та-ак. Даже мне стало интересно.
                        Дайте нам, пожалуйста, имена этих банков (особенно не-московских), а то меня терзают смутные подозрения, что мы вместе идеализируем виденное мной на протяжении нескольких лет ...

                        "Имя, сестра !"

                        Комментарий


                        • #13
                          Механизатор учёта
                          В точку!

                          Комментарий


                          • #14
                            Господа, неужели несколько громких имён окончательно укрепит Вас в Вашей точке зрения?! У меня перед глазами всего лишь один положительный пример, который для меня достаточно убедительным (при всех имевшихся проблемах)

                            2 Механизатор учета - привет однополчанам!

                            Сдается мне, что таки в ОДНОМ БАНКЕ ситуация с сопровождением (в широком смысле этого слова) со стороны IT департамента постепенно направлялась в нужное русло. Появилась унификация рабочих мест для ЦО, отделения, филиала - конечно, это было сделано в основном в целях бюджетирования , но тем не менее. А ещё, помнится, сотрудники технической службы самостоятельно бегали по принтерам и копирам и меняли эти самые картриджи. А ещё, помнится, как долго и тщательно мы согласовывали разные положения, описывающие бизнес-процессы, перед их автоматизацией - что весьма облегчало процессы разработки, внедрения, и тиражирования по разным доп. офисам и филиалам. И как при этом привлекался отдел обучения, и какую активную роль он играл...
                            Но это было давно, и всё это уже неправда. Поэтому и не осмеливаюсь произносить наименование этого банка

                            С уважением, Aha

                            Комментарий


                            • #15
                              Aha

                              Механизатор учета - привет однополчанам
                              Ты тоже на Первом Южноуральском банковском фронте воевал ?

                              Но это было давно
                              Только вот админов до конца построить не удалось ... Гордые очень, строем ходить не хотели ....

                              Комментарий


                              • #16
                                ASF

                                Говоря грубо, Aha, хотел донести мысль, что вместо затрат на внедрение ИС по интеграции IT-подразделений в целях качественного обслуживания всех и вся, дешевле завести тетрадку, в которую записывать, когда было последнее ТО (техобслуживание) у копира на 5 этаже, когда менялся картридж у лазера в комнате 622 (с окнами на ул. Социалистическую ) и т.п.

                                Что для этого нужно - всего лишь начать ....

                                Комментарий


                                • #17
                                  Механизатор учёта
                                  в которую записывать, когда было последнее ТО (техобслуживание) у копира на 5 этаже
                                  А еще на счетах считать можно Идея то понятна, только наверное никто, кроме пользователя, не знает сколько и чего он соберётся распечатывать именно на том принтере который в комнате 622 , поэтому как ни крути вызов человека для замены картриджа ложится на пользователя.
                                  И данный вопрос должен решаться с использованием единой системы HelpDesk..
                                  С уважением

                                  SunDog

                                  Комментарий


                                  • #18
                                    2 Механизатор учёта:
                                    Честно говоря не совсем моя область, но не удержусь и поддержу уважаемого Aha. Ведь все помнят лозунг "Болезнь легче предупредить, чем лечить". Но как только доходит до дела...
                                    ...вместо затрат на внедрение ИС по интеграции IT-подразделений в целях качественного обслуживания всех и вся, дешевле завести тетрадку, в которую записывать, когда было последнее ТО (техобслуживание) у копира на 5 этаже, когда менялся картридж у лазера в комнате 622...
                                    Да нет, не совсем так, точнее совсем не так.
                                    Если я правильно понял, то мысль уважаемого Aha не в тетрадке, а в построении бизнес-процесса поддержки пользователей. То есть, не ждать пока пользователь придет и закричит, что "...на этой ... 486-й машине ... даже Word запускается 20 минут...", а составить план Upgrade`а пользовательских машин и менять их в плановом порядке.
                                    Кстати, по поводу картриджей... Некоторые лазерные принтеры умеют показывать количество оставшегося порошка. Да и оценить примерно сроки смены картриджей не так уж трудно, накопив данные за 2-3-4 месяца о скорости расходования порошка/чернил.
                                    Мне кажется, что планирование бюджета от такого подхода только выиграет. Да и авралов станет на порядок меньше.
                                    Вот только боюсь, что переломить мышление руководства (да не кричит он(она), значит нормальный у него(не) компьютер (486-й)) будет очень непросто. Но, "Дорогу осилит идущий". Надо же нам хоть когда-нибудь начать жить по-уму, а не через мягкие и не очень места...

                                    Комментарий


                                    • #19
                                      SunDog

                                      Идея то понятна

                                      А мне показалось, что нет. Потому как первоначально вопрос звучал так: какой кал-центр нам нужно внедрить, чтоб общаться с юзерами.
                                      Прозвучал ответ Aha - всячески избегать возможных обращений через систему предусмотрительных мер, таких как планово-предупредительные ремонты, регламентирование рабочих мест и т.п.
                                      Понятно, что это не снимает таких обращений, как "забыл пароль" и т.п.

                                      А вот теперь вопрос, а чего нужно добиться, создавая хэлп-деск ? Как правильно звучит вопрос - чего-нибудь внедрить для этих целей или добиться регистрации входящих звонков и последующего анализа возникших проблем ?

                                      Как классифицировать проблемы ? Например, есть обращение пользователя об изменении/совершенствовании технологии выполнения операции, которая затрагивает несколько бизнес-подразделений. Что делать ? Кто должен заниматься согласованием такого изменения ?

                                      Таким образом, должна быть некоторая целостная картина результата, который необходимо достичЬ. А хэлп-деск можно создать по простому с помощью той же тетрадки и закреплением определённого номера внутренней АТС, просто пользователь на свой вопрос с проблемой должен услышать регистрационный номер своего вопроса для возможности дальнейшей трассировки. Как это будет организовано внутри IT - мелкие технические подробности.

                                      Комментарий


                                      • #20
                                        Хочу немного внести смуты в стройную концепцию Aha
                                        Правильная ссылка на Советский Союз и планово предупредительный ремонт. Но можно задать вопрос - и где тот СС ? - Обанкротился подчистую.

                                        А почему ? - Да потому что такая организация работы слишком дорога. Можно завести в каждом отделе по мальчику и научить его налаживать все и вся, но уверенности - что он после обучения навыки не потеряет - нет никакой.

                                        Кстати - аналогичная задачка (в бытность моей работы) стояла перед службами МЧС.
                                        Если понатыкать в каждом районе по части ГО, пожарной и прочим службам, оснастить их складами - то эффективность будет как ни казалось крайне низкой. Потому как пожары возникают случайно в разных местах - и может так оказаться что в той конкретной части он был всего единственный за все время службы. А раз так - то навыки будут чисто теоретические и квалификация служб никудышная. Можно завести систему тренировок, обучений. .. И опять никаких гарантий. Склады воруют, обновляют, оборудование портится и др.. - а это деньги, деньги, деньги..
                                        Решение было гениальное - создать _мобильные отряды_, которые будут _постоянно_ заниматься однотипной работой . Пусть и в разных концах России. Но время переброски отряда - сущая ерунда по сравнению с грехом непроффесионализма местных "спецов".

                                        Так вот - некий парадокс - для тех ситуаций, которые носят случайный и непредсказуемый характер - нужно делать такой "спецназ". Профилактика не поможет (дорого !) А если это плановые проблемы (кончается порошок, кончается место на диске, пользователь традиционно заносит вирусы) - нужно классифицировать по степени оперативности и увеличивать время автономной работы. Трудно поставить порошок в ксерокс неквалифицированному пользователю ? - Нафиг такой ксерокс или заключаем договор аутсорсинга с
                                        ксероксочинильной конторой.

                                        Но я согласен с мыслью - что чудес не бывает - либо оборудование дорого по кап. вложениям, а потом дешево по сопровождению или наоборот. Нужно внушать менеджменту - что машинам на коленке, Windows 98 в банке не место. Потом наплачешься сопровождать.

                                        Удачи !

                                        Комментарий


                                        • #21
                                          Прочитал постинг AHA, и представил эту благостную картину в отдельно взятом банке ...
                                          Идея то красива, и то, что "дорогу осилит идущий" тоже согласен. Только вот почему-то мне ближе позиция ASF , Pif и Механизатор учёта - не верю
                                          Взять хотя бы тезис, что сотрудники банка обучены. Извините, но текучка кадров во многих банках достигает просто неприличных размеров.
                                          Так что на практике все куда более коряво ...
                                          В чем полностью согласен с AHA, так это в том, что такой процесс предупреждения проблем должен быть организован. Но надо понимать, что никогда не будет 100% результата.

                                          Комментарий


                                          • #22
                                            Помню Сбербанк лет 5 назад.
                                            Были люди в обязанность которых входило ездить по подразделениям и проводить плановую профилактику...
                                            Были планы по смене железа...
                                            Были ограничения по ПО... Создание, приёмка, внедрение, доработка...
                                            Были созданы резервы критичных систем. Падший сервер восстанавливали на точнотакойже в течении 2 часов. В это время операционистки РУКАМИ считали(обробатывали) клиентов. Потому-что могли!
                                            Были отработаны технологии недающие пользователю поставить системы в ступор.
                                            Был жестко поставлен документооборот и резервные пути решения аварийных ситуаций...
                                            Всё это было... не в идиале, но работало довольно слаженно.
                                            Подавая сигналы в рог будь всегда справедлив, но строг. ©

                                            Комментарий


                                            • #23
                                              2 Механизатор учёта:
                                              Понятно, что это не снимает таких обращений, как "забыл пароль" и т.п.
                                              Прошу прощения, но мне кажется, что это совершенно не имеет отношения к данной дискуссии. То, что у нас с компьютерами работают люди нулевой и даже отрицательной квалификации - это наше горе, а не норма жизни. Вот сравните, разве на станок с ЧПУ (ну и стар же я, такое, небось, и помнят-то не все) допускали рабочего без обучения? Нет, а почему? Правильно - без обучения он угробит не только станок, но и себя и пару тройку коллег, оказавшихся рядом. А компьютер - он же "безобидный". Ну нет у нас до сих пор понятия, что информация стоит денег, и что потерянное рабочее время по причине отсутствия минимальных знаний сторудников - это тоже убытки и немалые.
                                              Прошу прощения, отвлекся.
                                              Как классифицировать проблемы ? Например, есть обращение пользователя об изменении/совершенствовании технологии выполнения операции, которая затрагивает несколько бизнес-подразделений. Что делать ? Кто должен заниматься согласованием такого изменения ?
                                              Извините, уважаемый Механизатор учёта, но такого рода вопросам не место на HelpDesk. Если в организации нет технолога, который следит за соблюдением и совершенствованием технологий, то это либо очень маленькая организация (с огромной долей ручного труда), либо кандидат на банкротство.
                                              Хотелось бы поддержать уважаемого Romsan, сбербанк со всеми его бюрократизмами очень неплохой пример построения планового хозяйства. А ведь он, в отличие от СССР, жив здоров и помирать пока (тьфу-тьфу-тьфу) не собирается.

                                              Комментарий


                                              • #24
                                                Cost

                                                Извините, уважаемый Механизатор учёта, но такого рода вопросам не место на HelpDesk.
                                                Нет, это Вы меня извините, но в первоначальном постинге была фраза о едином телефоне от IT для всех обращений пользователей. Отсюда и мой вопрос - как классифицировать и сепарировать проблемы ? Вы предлагаете производить классификацию проблемы / предложения на уровне самосознания пользователя, т.е. проблема с картриджем - go to хэлп-деск aka кал-центр, изменение технологии - go to банковский технолог. Таким образом, 2 независимых потока заявок. Оно нужно ?

                                                Т.е. мы обсуждаем не необходимость наличия технологов (это бесспорный медицинский факт, как говорил один знакомый "народный целитель"), а организацию прозрачного процесса фиксирования, классифицирования, сепарирования, исполнения и отслеживания заявок.

                                                Комментарий


                                                • #25
                                                  Shamai
                                                  Извините, но текучка кадров во многих банках достигает просто неприличных размеров.
                                                  Данную проблему надо решать на более ином уровне и более иными методами (зряплата, условия труда и т.д.), но это место дрогого форума

                                                  Механизатор учёта
                                                  Например, есть обращение пользователя об изменении/совершенствовании технологии выполнения операции, которая затрагивает несколько бизнес-подразделений
                                                  Однозначно принимать там же с использованием того же call-центра, но естественно по заранее прописанной процедуре с заполнением форм и прочее.
                                                  т.е. служба helpdesk в этом случае будет будет играть роль некого кеша который принимает задания и согласно заранее прописанным бизнес-процессам передаёт в дальнейшую отработку..
                                                  у пользователя появляется "спасительный" телефон аналогичный америкосовскому 911.
                                                  С уважением

                                                  SunDog

                                                  Комментарий


                                                  • #26
                                                    2 Механизатор учёта:
                                                    Вы предлагаете производить классификацию проблемы / предложения на уровне самосознания пользователя, т.е. проблема с картриджем - go to хэлп-деск aka кал-центр, изменение технологии - go to банковский технолог.
                                                    Наверно я не смог четко донести смысл своего постинга. Попробую еще раз.
                                                    IMHO, среднестатистический пользователь является потребителем технологии, а не инициатором ее создания и изменения. То есть, если пользователь звонит в автоматизацию и говорит примерно: "...тут в экране ввода платежного поручения нужно ХХХ поле убрать, YYY заменить на ZZZ...", то рассматривать данную заявку вряд ли необходимо. Есть единственный случай, когда такого рода заявку надо рассматривать - если данная технология касается исключительно данного пользователя. Но таких технологий на практике мне не встречалось. А бросаться даже рассматривать изменение технологии, если Марии Ивановне удобнее нажимать стрелочку, а не Enter, если ей приятнее носить бумажный документ Васе, а не Пете, если она хочет визировать документ после ГлавБуха, а не перед ним - это, простите, пустая трата времени. На то и существует технолог, чтобы технология удовлетворяла всем участникам процесса, а не лично каждому.
                                                    Надеюсь теперь я буду верно понят.

                                                    Комментарий


                                                    • #27
                                                      SunDog

                                                      Однозначно принимать там же с использованием того же call-центра, но естественно по заранее прописанной процедуре с заполнением форм и прочее
                                                      Правильно, при таком подходе "911" IT имеет единый центр фиксирования и диспетчеризации заявок, соответственно есть инструменты для внутреннего анализа.
                                                      Однако как и любой другой процесс, приём заявок в IT должен быть формализован. А как формализовать заявку на изменение технологии, как поставить её в один ряд с заявками на замену картриджа ?

                                                      Cost

                                                      IMHO, среднестатистический пользователь является потребителем технологии, а не инициатором ее создания и изменения.

                                                      Имхо на то и имхо, потому что отражает имхо.
                                                      В действительности всё гораздо сложнее. По Вашим словам, за изменение технологии отвечает технолог, однако никакой технолог не может быть инициатором изменения (ну нет у него таких полномочий), технолог всего лишь средство изменения, двигатель этого процесса. А инициатор известен всегда - ЛПР (лицо, принимающее решения), т.е. представитель бизнес-подразделений.
                                                      Поэтому без заявок не обойтись.

                                                      Комментарий


                                                      • #28
                                                        2 Механизатор учёта:
                                                        Конечно, технологии у всех разные. Я, в основном, сталкивался с ситуацией: возникает необходимость в смене технологии (новая операция, изменение объемов, параметров выполнения операции и т.д.) -> выпускается приказ по организации (ЛПР`ом) -> приказ доводится до технолога штатным порядком (наряду с остальными заинтересованными лицами) -> технолог разрабатывает технологию и внедряет ее в функциональное подразделение.
                                                        А один раз, и правда, видел систему когда к программисту бегают все подряд и подают заявки в устном и письменном виде на изменение технологий. Последствия исполнения этих заявок, даже с учетом согласования и прочая, без содрогания вспомнить не могу.
                                                        Именно поэтому я и начал высказываться в поддержку уважаемого Aha.

                                                        Комментарий


                                                        • #29
                                                          2 Механизатор учёта:
                                                          А как формализовать заявку на изменение технологии, как поставить её в один ряд с заявками на замену картриджа ?
                                                          А чем Вам для данного дела не нравится, скажем, Intersolv PVCS Tracker или подобные системы? Они как раз обладают механизмом ввода и поддержкой жизненного цикла заявок - механизмом подачи заявки, расстановкой приоритетов, отметок о выполнении и т.д.

                                                          Комментарий


                                                          • #30
                                                            Механизатор учёта
                                                            IMHO формализации поддаётся любой процесс в том числе и на изменение технологий.. естественно мальчик/девочка поднявший трубку на телефоне call-центра совершенно не должна со слов записать пожелания пользователя, но обязана уведомить о том что.. ну например существует форма которую они смогут заполнить и отправить всё в ту же службу далее она будет рассмотренна и на заявку будет наложена резолюция, будет выделено ответственное подразделение.. после внесения изменений пользователь не обращается в подразделение(я) которые вносили изменения а обращается в ту же службу call-центра..
                                                            С уважением

                                                            SunDog

                                                            Комментарий

                                                            Пользователи, просматривающие эту тему

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X