Управление качеством в банке
Методики управления качеством программных продуктов (TickIT) для ИТ-менеджмента: понятие о всеобщем управлении качеством, принципы Деминга и стандарты серии ISO 9000. Жизненный цикл программного обеспечения и удовлетворение потребностей потребителя.
| Рубрика | Банковское, биржевое дело и страхование |
| Вид | реферат |
| Язык | русский |
| Дата добавления | 12.08.2011 |
| Размер файла | 27,0 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Управление качеством в банке
Введение
Постоянной головной болью ИТ-менеджеров являются претензии пользователей по качеству продуктов и услуг. При этом каждому практикующему ИТ-менеджеру очевидно, что окончательно избавиться от претензий, наверно, невозможно, но существенно сократить их, добиться в целом положительной оценки деятельности ИТ-службы или работы отдельных программ - вполне реальная и необходимая задача, которая является одной из базовых задач ИТ-менеджмента и оперативного управления ИТ. Рассмотрим основные направления такой работы.
В современном расширенном толковании качество понимается как способность продукта или услуги удовлетворить потребности и ожидания каждого конкретного потребителя. Если деятельность ИТ-службы не соответствуют ожиданиям каждого конкретного клиента-пользователя, другими словами - качество ИТ-услуг низкое, то это может быть источником сбоев в работе, снижения авторитета ИТ-подразделения, недостатка финансирования со стороны бизнес-подразделений и т.п. Поэтому при организации работы ИТ-службы прежде всего необходимо ориентироваться на удовлетворение потребностей пользователей и совершенствование системы контроля и управления качеством.
За рубежом разработаны и успешно применяются на практике различные методики управления качеством, как общие (TQM, Six Sigmas, IS09000), так и специализированные, предназначенные для управления качеством программных продуктов (TickIT).
1. Всеобщее управление качеством (TQM)
Одной из основополагающих и широко используемых в международной практике концепций, помогающих руководителям решать задачи контроля и управления качеством, является методология "Всеобщее управление качеством" (Total Quality Management, TQM). Мы полагаем, что в современных условиях она вполне применима для ИТ. Но прежде чем мы рассмотрим ее основные положения и возможности их применения, необходимо остановиться на истории создания TQM.
Концепция всеобщего управления качеством зародилась в США, а в полном объеме впервые была реализована в Японии. Именно американские ученые-экономисты Эдвард Деминг (1900-1993) и Джозеф Джуран (1903-1993), направленные, согласно плану Маршалла, для оказания помощи разрушенной в ходе войны экономике Японии, впервые сформулировали те общепризнанные сегодня принципы, которые и составили концептуальную основу TQM. Эти принципы стали главной составляющей феномена, так хорошо всем известного под названием "японское чудо".
В основу концепции TQM легли базовые принципы, сформулированные и изложенные Демингом:
* улучшение качества продукции и услуг должно стать постоянной и приоритетной задачей для всей организации, в том числе и для высшего руководства;
* необходимо внедрять новую философию и отношение к окружающим процессам;
* постоянно соотносить качество и удовлетворенность потребителя с ценой;
* вести постоянное обучение, прежде всего на рабочем месте;
* устранять барьеры между подразделениями;
* искоренять страх перед переменами;
* дать возможность всем служащим гордиться принадлежностью к организации;
* всячески поощрять образование и самосовершенствование;
* вовлечь каждого в работу по преобразованию;
* избегать пустых лозунгов;
* организовать руководство таким образом, чтобы его основным предназначением была помощь работникам;
* отказаться от контроля качества только посредством проверок и ревизий;
* стремиться к постоянному улучшению всей системы функционирования организации;
* искоренять "уравниловку" персонала.
Идея концепции всеобщего управления качеством, основанная на этих принципах, - глобальное расширение понятия качества и утверждение процесса управления им как основной задачи менеджмента.
Согласно TQM общее управление качеством (или системой качества) включает такие составляющие, как оперативное управление качеством на всех стадиях жизненного цикла, обеспечение внутреннего и внешнего качества, планирование и улучшение качества. При стратегической нацеленности на изложенные выше принципы, участии руководства и всех сотрудников организации в этих процессах возникает всеобщее управление качеством.
Обеспечение должного уровня качества включает комплекс средств, направленных на достижение уверенности в качестве продукта или услуги у внешних и внутренних потребителей (существующих и потенциальных клиентов, персонала и партнеров организации).
Планирование и улучшение качества являются также постоянными составляющими, обеспечивающими прогнозирование и постоянное увеличение требований к оперативному управлению и обеспечению качества услуг. Основной целью всей системы контроля качества, как уже отмечалось, должно стать максимально полное удовлетворение потребностей пользователей.
2. Стандарт качества ISO 9000
Остановимся на основных моментах управления качеством услуг в соответствии со стандартами серии ISO 9000. Для этого прежде всего обратимся к его терминам и определениям.
Программное обеспечение - интеллектуальный продукт, состоящий из программ, процедур, правил и любой другой связанной с ними документации, относящейся к функционированию системы обработки данных.
Элемент программного обеспечения - какая-либо идентифицируемая часть продукции программного обеспечения на промежуточном или конечном этапе разработки.
Разработка - все виды деятельности, выполняемые для создания программного обеспечения.
Проверка программного обеспечения - процесс оценивания продукции данной фазы в целях обеспечения правильности и согласованности в отношении продукции и стандартов, являющихся входными для данной части работы (фазы).
Аттестация программного обеспечения - процесс оценивания программного обеспечения в целях обеспечения соответствия установленным требованиям.
Услуга - итог непосредственного взаимодействия поставщика (Supplier) и потребителя (Customer), а также внутренней деятельности поставщика по удовлетворению потребности потребителя.
Предоставление услуги (Service Delivery) - деятельность поставщика, необходимая для обеспечения услуги.
Качество услуги - совокупность свойств и характеристик услуги, обеспечивающих удовлетворение обусловленных или предполагаемых потребностей.
Требования к качеству - выражение определенных (установленных или предполагаемых) потребностей потребителя и их перевод в набор количественных или качественных оценок характеристик услуги.
Характеристики услуг подразделяются на виды: характеристики процесса предоставления услуги и характеристики самой услуги. Характеристики (оба вида) должны обладать способностью оцениваться. Оценка возможна количественная (измеряемая) и качественная (сопоставимая). Характеристики процесса предоставления услуги в основном не определяются потребителем, они служат обоснованием и доказательством того, что характеристики самой услуги будут обеспечены на заявленном уровне.
Стандарт ISO 9000 помимо основной терминологии регламентирует процесс подготовки и предоставления услуги, а также систему качества.
Принято считать, что достижение требуемого качества возможно благодаря строгому следованию этапам (или основным составляющим) процессов, описанных в стандарте, и работе по общему управлению качеством (или системе качества). Рассмотрим применяемую на практике методику подготовки услуги, соответствующую стандарту ISO 9000, и ее этапы.
Определение будущей услуги базируется на аналитическом исследовании деятельности и потребностей существующих и потенциальных клиентов. При анализе должна учитываться точка зрения потребителя на все аспекты услуги. Процедура определения может состоять из следующих шагов.
Шаг 1. Определить и поименовать потребность, подлежащую удовлетворению услугой.
Шаг 2. Определить, в какой потенциальной группе клиентов эта потребность существует.
Шаг 3. Описать ту часть услуги (работу, результаты работы и т.д.), которая удовлетворит выявленную потребность.
Шаг 4. Определить, по каким характеристикам клиент будет оценивать услугу и степень удовлетворения услугой своей потребности.
Спецификация услуги - основополагающий документ, содержащий основные составляющие и потребительские свойства услуги, разрабатывается на основе принятого определения услуги. Документ является первым в пакете проектной документации по услуге. После утверждения документ используется в процессе продвижения и управления качеством услуги.
Спецификация процессов предоставления услуги - документ, определяющий основные этапы работы и ресурсы, гарантирующие предоставление услуги в соответствии с ее спецификацией. Спецификация процессов должна содержать: методики предоставления услуги (инструкции по выполнению работ для персонала кредитной организации), способы предоставления (описание инициирующих условий, организационных действий поставщика и потребителя, формы и способы взаимодействия, временные и территориальные ограничения), информационные материалы, процедуры разрешения спорных ситуаций, шаблоны договоров и прочие документы по услуге.
Спецификация управления качеством. Этот этап должен включать определение ключевых работ, существенно влияющих на качество предоставления услуги, выборку и анализ характеристик предоставляемой услуги, определение методов оценки характеристик в процессе предоставления услуги, определение средств влияния на улучшение качества услуг.
Подготовка персонала. Персонал - основной ресурс, определяющий качество услуги. Руководитель подразделения, участвующий в процессе предоставления услуги, обязан: определить квалификационные требования, необходимые и достаточные для выполнения конкретной работы; подбирать/назначать сотрудников, удовлетворяющих квалификационным требованиям; обеспечить условия выполнения работы, обращать внимание сотрудников на то, что их работа напрямую влияет на уровень качества услуги; стимулировать и поощрять усилия персонала, направленные на повышение качества. Руководитель подразделения в плановом порядке обязан проводить мероприятия по совершенствованию профессиональных навыков и умений сотрудников.
Реклама и продвижение услуги. Для формирования и разработки рекламной политики и программы продвижения услуг необходимо использовать спецификации услуг и процессов их предоставления.
Клиент, читая или рассматривая рекламу, должен находить ответы наследующие вопросы, определяющие сегодня конкурентоспособность услуги.
Существует ли у меня неудовлетворенная потребность из тех, что описаны в рекламных материалах?
Соизмеряется ли стоимость услуг с их качеством?
Действительно ли поставщик способен оказать необходимую услугу?
Насколько выгоднее обратиться к данному поставщику, чем к другим?
Рассмотрим теперь элементы системы качества, необходимые для ее соответствия требованиям стандарта ISO 9000. Для этого введем точное определение этого термина. Стандарт ISO 9000 использует определение из ISO 8402: система качества - это совокупность организационной структуры, методик, процессов и ресурсов, необходимых для общего управления качеством. Все эти элементы системы качества должны быть задокументированы. Документация должна давать четкие гарантии, что элементы системы качества обеспечивают потребителю получение качественной услуги - выполнение обещаний поставщика услуги, а также удовлетворение потребности и ожиданий потребителя.
В стандартах серии ISO 9000 предыдущих редакций содержались рекомендации по управлению качеством программных продуктов. Сформулируем основные из них.
Ответственность, полномочия и взаимодействие всего персонала, который руководит, выполняет и проверяет работу, оказывающую влияние на качество, должны быть четко определены.
Анализ проекта и проверки системы качества, процессов, услуг и/или программ должны выполняться персоналом, независимым от тех, кто несет непосредственную ответственность за выполненную работу.
Поставщик должен назначить представителя руководства, который, независимо от других обязанностей, должен иметь определенные полномочия и нести ответственность за выполнение и соблюдение требований стандартов качества.
Покупатель (клиент) должен сотрудничать с поставщиком с целью обеспечения его всем необходимым для разрешения возникающих проблем.
Покупатель (клиент) должен назначить ответственного со стороны руководства за связь с поставщиком. Этот представитель должен иметь необходимые полномочия для решения следующих вопросов: определения требований; ответов на вопросы поставщика; заключения соглашений и прием предложений; гарантировать соблюдение соглашений; определять порядок и критерии приемки решения; принимать решения по тем элементам программного обеспечения, которые признаны непригодными.
Регулярный совместный анализ, проводимый заказчиком и поставщиком, должен планироваться так, чтобы охватить следующие вопросы: соответствие программного обеспечения техническому заданию, согласованному с покупателем; результаты контроля; результаты приемочных испытаний. Результаты анализа должны быть документированы.
Система качества должна представлять собой единый процесс, проходящий через весь жизненный цикл продукции, гарантируя, что качество соблюдается в ходе всего процесса разработки и поставки. Упор необходимо делать на предупреждение появления дефектов, а не на исправление их после возникновения.
Поставщик должен документально оформить план качества и осуществлять регулярные проверки в соответствии с ним.
Поставщик должен документально оформлять и выполнять процедуры, обеспечивающие: выявление причин несоответствия продукта и корректирующие воздействия, предупреждающие возникновение дефекта; анализ всех процессов и рекламаций потребителей с целью выявления и устранения потенциальных причин; проведение профилактических действий для решения проблем на уровне, соответствующем реальному риску; осуществление контроля, внедрение изменений в процедуры и процессы.
Для обеспечения механизма идентификации, контроля каждого элемента программного обеспечения используется управление конфигурацией. Система управления конфигурацией должна: однозначно идентифицировать каждый вариант элементов программного обеспечения; идентифицировать варианты элементов программного обеспечения, которые вместе образуют конкретный вариант готового продукта; управлять одновременной модернизаций конкретного элемента продукта, проводимой более чем одним человеком; обеспечивать координацию работы; идентифицировать и отслеживать все мероприятия.
Проект разработки программного обеспечения должен осуществляться в соответствии с моделью жизненного цикла программного обеспечения, который будет рассмотрен ниже.
3. Жизненный цикл программного обеспечения
Жизненный цикл программного обеспечения влияет на многие составляющие ИТ-менеджмента, но мы рассматриваем его в данной главе, потому что, по нашему мнению, он наиболее удачно сформулирован в стандартах управления качеством серии ISO 9000. По ним жизненный цикл ПО состоит из следующих составляющих.
Анализ контракта. Поставщик должен устанавливать и выполнять процедуры, обеспечивающие проведение анализа контракта и координацию этой деятельности. Каждый контракт должен быть изучен поставщиком с целью гарантии того, что область действия контракта и требования определены и документированы, риски идентифицированы, конфиденциальная информации защищена, поставщик и потребитель имеют возможности выполнить контрактные требования; определена ответственность сторон, терминология согласована.
С точки зрения качества целесообразно включение в контрактные документы следующих пунктов: критерии приемки; учет изменений в требованиях заказчика в процессе разработки; проработку проблем, выявленных в ходе приемки; ответственность заказчика за подготовку требований, приемку и т.п.; средства, инструменты и элементы поставляемого программного комплекса; применяемые стандарты и процедуры; особенности тиражирования.
Техническое задание заказчика. Для разработки программного обеспечения поставщик должен иметь полный и однозначный набор функциональных требований. Кроме того, эти требования должны отражать все аспекты, необходимые для удовлетворения потребностей покупателя (например, эксплуатационные качества, требования безопасности, конфиденциальности и надежности). Эти требования должны быть сформулированы достаточно точно, чтобы производить необходимую оценку в процессе приемки. Все требования должны документально оформляться. Как правило, это осуществляется заказчиком или совместно. При этом окончательный вариант технического задания должен обязательно взаимно согласовываться. Технические задания должны использоваться в процессе управления конфигурацией.
В процессе разработки технического задания рекомендуется обратить внимание на следующие вопросы: назначение лиц с обеих сторон, ответственных за разработку технического задания; методы согласования требований и утверждения изменений; определение терминов, разъяснение исходных данных в отношении требований и прочие действия, которые способствуют устранению взаимного непонимания; документирование дискуссий и обсуждений.
Планирование разработки. План разработки должен охватывать: описание проекта, включая постановку задачи; организацию управления и ресурсы проекта (состав команды); фазы разработки; программу работ над проектом, устанавливающую задачи, которые должны быть решены, распределение их по имеющимся ресурсам, временные рамки; взаимную увязку мероприятий. План разработки должен корректироваться по ходу осуществления работ, при этом каждая фаза должна быть четко описана до начала работ по ней.
План разработки должен устанавливать упорядоченный процесс или методологию преобразования технического задания заказчика в конечный продукт. Он может включать в себя распределение работ по фазам, необходимые затраты по каждой фазе, требуемые результаты, процедуры проверки и приемки, анализ потенциальных проблем, связанных с фазами разработки и выполнением установленных требований. Также в нем должны отражаться механизмы управления проектом, в том числе план-график работ, контроль за ходом проекта, ответственность сторон и участников, система взаимодействия между различными участниками работ. Следующей составляющей плана разработки должны быть методы и средства разработки, технические приемы, используемые в ходе реализации, конфигурационный менеджмент.
Еще одним необходимым элементом планирования разработки должен быть анализ хода выполнения разработки, который должен осуществляться на регулярной основе и оформляться документально с тем, чтобы обеспечить решение спорных вопросов и гарантировать эффективное выполнение задачи.
Результаты выполнения каждой фазы должны быть определены и документально оформлены. Они должны быть проверены и удовлетворять следующим условиям: отвечать установленным для каждой фазы требованиям; содержать критерии приемки; соответствовать принятой практике и опыту разработки независимо от того, оговорены ли они во входной информации; соответствовать действующим нормативным требованиям.
Проверка разработки должна осуществляться после каждой фазы и определять, соответствует ли представленное решение требованиям, установленным в начале фазы. Эти проверки могут производиться в форме испытаний или демонстрационных показов. Только проверенные результаты разработок должны быть представлены на рассмотрение для управления конфигурацией и приняты для последующего использования.
Планирование качества. Поставщик должен подготовить план качества как часть работ по планированию разработки. Данный документ должен содержать: цели качества, выраженные в измеряемых показателях; заданные критерии по затратам и результатам для каждой фазы разработки; идентификацию видов деятельности, связанной с испытаниями, проверками, оценками, которые должны быть проведены; детальное распределение ответственности за мероприятия по обеспечению качества, такие, как анализы и испытания, управление конфигурацией и контроль за изменениями, контроль дефектов и корректирующие воздействия.
Проектирование и реализация. Проектирование и реализация - это те виды деятельности, которые трансформируют техническое задание заказчика в конечный программный продукт. Уровень раскрытия информации между сторонами должен быть взаимно согласован, так как часто процессы и технология проектирования и реализации являются собственностью поставщика.
В дополнение к требованиям, общим для всех фаз жизненного цикла, необходимо учитывать следующие аспекты, присущие проектированию. В ходе работ должна использоваться методология системного проектирования, соответствующая виду разрабатываемого ПО. Необходимо использовать накопленный опыт во избежание повторения прошлых ошибок проектирования. Продукт должен быть спроектирован так, чтобы можно было без помех проводить испытания, техническое обслуживание и использовать продукт.
При реализации следует применять единые правила, которые включают правила программирования, языки и среды разработки, согласованные правила наименования, кодирования и соответствующих комментариев. Поставщик должен использовать методологию разработки. Должен проводиться регулярный анализ с целью проверки соблюдения установленных методологических подходов.
Испытание и оценка качества. Проведение испытаний может быть необходимо на различных уровнях, от отдельного элемента программного обеспечения до готовой продукции. Существует несколько различных подходов к испытаниям. В некоторых случаях оценка испытания на месте и приемочные испытания могут быть одним и тем же видом деятельности.
Поставщик должен составить и согласовать план испытаний, технические условия и процедуры испытаний до начала работ, связанных с проведением испытаний. Этот план включает: детальные планы по различным испытаниям, оценке, приемочным работам; ожидаемые результаты; типы планируемых испытаний; внешние условия при испытаниях; инструментальные средства; критерии окончания испытаний; пользовательскую документацию; необходимый персонал и требования, связанные с его обучением.
Особое внимание рекомендуется обратить на следующие стороны испытаний: результаты испытаний должны быть запротоколированы; любые обнаруженные проблемы и их возможное влияние на остальные части программного обеспечения должны быть отмечены, и об этом должны быть извещены ответственные исполнители с тем, чтобы проблемы могли быть отслежены до тех пор, пока они не будут решены; области, которые подвергались модификации, должны быть идентифицированы и повторно испытаны; должна быть оценена адекватность и релевантность испытаний; конфигурация программных и аппаратных средств должна быть согласована и задокументирована.
Прежде чем предложить продукцию для поставки и приемки покупателям, должна быть осуществлена оценка ее функциональных качеств, по возможности в условиях, аналогичных условиям применения.
Приемка. Если поставщик готов поставлять продукцию, прошедшую оценку и испытания, заказчик должен решать, приемлема она или нет, согласно ранее принятым критериям и порядку, оговоренному в контракте. Метод и порядок решения проблем, обнаруженных во время приемки, должны быть согласованы между покупателем и поставщиком и оформлены документально. При проведении приемочных испытаний поставщик должен оказать содействие заказчику в вопросах определения временного плана работ, методик, программных сред и ресурсов, критериев приемки.
Тиражирование, поставка и монтаж. Необходимо обеспечить условия для проверки правильности и полноты копий поставляемой продукции. Роль, ответственность и обязательства поставщика и заказчика должны быть четко оговорены, в том числе доступ к техническим средствам, план-график, формальные процедуры приемки продукта после поставки (монтажа).
Обслуживание. Если заказчик требует проведения технического обслуживания программного обеспечения после первоначальной поставки и монтажа, это должно быть оговорено в контракте. Поставщик должен установить и осуществить процедуры по техническому обслуживанию, с тем чтобы удостоверить, что подобные действия удовлетворяют установленным в контракте требованиям к техническому обслуживанию.
Виды деятельности, связанные с техническим обслуживанием программного обеспечения:
- решение проблем;
- модификация интерфейса;
- расширение функций и улучшение эксплуатационных характеристик.
Элементы, которые должны быть обслужены, и период времени обслуживания должны оговариваться в контракте. Такими элементами могут быть программы, данные и их структура, спецификации, документация.
Все виды деятельности, связанные с техническим обслуживанием, должны осуществляться и управляться в соответствии с планом, составленным и согласованным заранее. В таком плане должны быть отражены: область технического обслуживания, первоначальный статус продукта, организация обслуживания, виды деятельности по обслуживанию, протоколы и отчеты по обслуживанию.
Все действия, осуществляемые в процессе обслуживания системы, должны осуществляться в соответствии с подходами, используемыми при разработке программного обеспечения, насколько это возможно.
Протоколы технического обслуживания должны включать в себя следующие пункты: перечень заявок с указанием текущего состояния по каждой; ответственное лицо; приоритеты, которые были установлены для корректирующих действий; результаты коррекции; статистические данные о случаях отказа и действиях по обслуживанию. Протокол обслуживания может быть использован для оценки и модернизации продукта и совершенствования системы качества.
Стороны должны согласовать между собой и документально оформить процедуры, связанные с внесением изменений в программное обеспечение в результате необходимости поддерживать эксплуатационные характеристики:
основные правила, определяющие, в каких случаях можно внести исправления, а в каких необходим выпуск полностью обновленной копии программного обеспечения;
описание типов (или классов) выпусков в зависимости от их частоты и воздействия на деятельность заказчика;
способы уведомления об изменениях;
методы, подтверждающие, что осуществленные изменения не повлекут за собой возникновения новых проблем;
требования к протоколам, указывающим, где и как производились изменения, их сущность в случае сложности продукции или наличия нескольких мест производства.
4. Специализированный стандарт TickIT
Специализированный стандарт TickIT - это схема сертификации систем качества для программного обеспечения, предложенная группой ведущих фирм и некоммерческих организаций Великобритании, работающих в области информатики. Контроль и спонсирование схемы осуществляется DTI. TickIT базируется на стандарте ISO 9001:1994, который был рассмотрен выше. Таким образом, предметом TickIT является менеджмент предприятий, разрабатывающих программное обеспечение.
Помимо своей основы (стандарта) ISO 9001 TickIT содержит следующие компоненты:
- руководство по TickIT, базирующееся на указаниях ISO 9000-3 (руководство по системам качества для программного обеспечения);
- схему регистрации аудиторов через специальный комитет по TickIT IRCA (Международный регистр сертифицированных аудиторов);
- систему проверок аудиторов Британским компьютерным обществом (BCS) и Институтом по обеспечению качества (IQA);
- систему аккредитации сертификационных обществ - UKAS (Великобритания), SWEDAC (Швеция);
- программы, направленные на расширение признания схемы;
- трехлетний цикл пересмотра схемы;
- систему специальных премий за достижения.
Гибкая инфраструктура TickIT позволяет схеме следовать изменениям в этой весьма динамичной отрасли, обеспечивая тем самым ее постоянное совершенствование.
В последней редакции руководства по TickIT активно используется идеология жизненного цикла программного обеспечения. Основные определения процессов жизненного цикла программного обеспечения даны в другом стандарте - ISO/IEC 12207, который может служить основой при выборе конкретной модели процессов жизненного цикла на предприятии. Таким образом, схема TickIT использует рациональное начало, заложенное в методах совершенствования процессов, таких, как СММ (Carnegie Mellon University), Trillium (Bell Canada), BOOTSTRAP и т.д. Великобритания традиционно занимает лидирующее положение в области стандартизации, поэтому неудивительно, что инициатива TickIT изначально принадлежит Великобритании.
Несмотря на британское происхождение, TickIT широко применяется и в других странах. В списке предприятий, сертифицированных по схеме TickIT, в настоящее время присутствуют названия более 40 государств. Марка и логотип TickIT пользуются заслуженным международным авторитетом. Получение сертификата TickIT является важным шагом любой европейской софтверной фирмы на пути к завоеванию признания на рынке. По данным на май 1997 года, в Великобритании было выдано 956 сертификатов TickIT, в других странах - 338. Растет количество сертификатов, выданных за пределами Великобритании. Предполагается, что дальнейшее расширение использования схемы TickIT приведет к созданию международной европейской схемы с аккредитацией согласно EN45012/3.
По схеме TickIT могут быть сертифицированы системы качества предприятий, занимающихся следующими видами деятельности:
* разработкой программного продукта или услуги как для внешнего заказчика, так и для внутреннего использования, включая встроенное (embedded) программное обеспечение;
* копированием, архивированием, хранением данных и программным обеспечением;
* системной интеграцией, поддержкой, администрированием и др.
Приведенный выше список является примерным, применимость схемы в том или ином случае оценивается отдельно. Виды деятельности, в которых разработка программного обеспечения отсутствует (например, розничная или оптовая продажа коробочного программного обеспечения), не могут быть сертифицированы согласно TickIT.
Для того чтобы получить сертификат TickIT и использовать логотип TickIT, в организации или предприятии должна быть подготовлена и внедрена система управления качеством в соответствии с требованиями и рекомендациями схемы. Это потребует усилий как со стороны руководства предприятием, так и рядовых сотрудников. Система качества должна функционировать на предприятии в течение некоторого времени, прежде чем можно будет обратиться в сертификационное общество с целью проведения аудита и выдачи сертификата. Такой период адаптации необходим для того, чтобы система качества полностью интегрировалась в систему менеджмента предприятия и это можно было продемонстрировать в процессе аудита. Сертификационный аудит проводится в несколько этапов в соответствии со стандартной процедурой.
ит качество потребитель tickit
5. Особенности управления качеством ИТ-услуг
Если кредитная организация осознает необходимость улучшения качества предоставляемых ею ИТ-услуг и согласна с концепцией всеобщего управления качеством, целесообразно рассмотреть основные подходы к управлению качеством ИТ-услуг. Существуют два основных направления такой работы: управление качеством при разработке ИТ-услуг и управление качеством при предоставлении услуг пользователям.
Этапы разработки новых услуг и управления их качеством были перечислены выше, однако стоит отметить, что кредитная организация не обязательно должна опираться на какие-либо стандарты в этой области. Концепция всеобщего управления качеством не подразумевает жесткого использования стандартов. Важно лишь помнить стратегическую задачу и цели проводимых работ по улучшению качества.
Остановимся на управлении качеством в процессе предоставления услуг. Для этого рассмотрим некоторые рекомендации, которые необходимо учесть на начальном этапе данного процесса:
- в большинстве случаев управление качеством услуги возможно только путем контроля процесса предоставления услуги. Категорически не рекомендуется полагаться только на контроль конечного результата;
- для обеспечения требуемого уровня качества необходимо иметь детальные спецификации (описания) услуг и процесса их предоставления. Как показывает практика, большинство банков сегодня их не имеет или не контролирует соответствие процесса предоставления услуги утвержденному регламенту;
- требуется разработать и внедрить систему, позволяющую своевременно получать информацию о качестве, конкурентоспособности и стоимости услуг. При этом необходимо учитывать возникающие при предоставлении услуги проблемы и пожелания пользователей по их преодолению. Необходимо также принимать во внимание мнение руководства, персонала и специальных служб (внутренний аудит, контроль, служба качества) организации;
- оценить и выработать программу внедрения стратегических составляющих качества услуг (по TQM), таких, как обучение и повышение квалификации персонала, внедрение новой философии управления, вовлеченность персонала в процессы контроля и повышения качества услуг, создание позитивного имиджа банка;
- выработать и внедрить систему материального стимулирования персонала за качественную работу, где существенная часть фонда заработной платы будет прямо соотносима с качеством выполнения работы исполнителем и качеством услуг банка в целом. При такой системе каждый сотрудник должен быть заинтересован не только в том, как он лично выполняет работу, но также в том, насколько качественно выполняют ее его коллеги, поскольку каждый из сотрудников должен нести частичную материальную ответственность и за ошибки других.
После того как эти первостепенные мероприятия дадут свои результаты, можно приступать к дальнейшим шагам, например сертификации.
С другой стороны, даже независимо от задачи сертификации приведение процедур управления качеством в соответствие с требованиями концепции всеобщего управления качеством и стандарта ISO 9000 существенно продвинет организацию и послужит залогом ее будущего развития.
Размещено на Allbest.ru
Подобные документы
Сущность и специфика системы управления качеством банковских услуг. Оптимизация процесса обслуживания клиентов на примере деятельности Бугульминского ОСБ. Обоснование возможных путей решения проблем управления качеством услуг кредитования населения.
дипломная работа [119,1 K], добавлен 08.12.2010Основные составляющие системы управления качеством в Сбербанке России. Качество услуг, предоставляемых Сбербанком России. Анализ системы управления качеством предоставляемых услуг и качеством клиентского обслуживания на примере Омского ОСБ № 8634 г. Омска
дипломная работа [172,6 K], добавлен 23.05.2015Экономическая сущность и показатели оценки качества кредитного портфеля. Анализ современной практики управления качеством кредитного портфеля на примере АКБ "Инвестбанк". Приоритетные пути решения проблем в сфере менеджмента качества кредитных вложений.
дипломная работа [140,1 K], добавлен 26.09.2010Контроль как составляющая процесса управления качеством. Анализ состояния обслуживания клиентов в Банке "Ренессанс Капитал" (ООО). Разработка рекомендаций по совершенствованию качества контроля обслуживания клиентов в Банке "Ренессанс Капитал".
дипломная работа [1,3 M], добавлен 23.08.2011Характеристика ОАО "Сбербанк России". Организационная структура управления, действующее законодательство, нормативные документы банка. Анализ финансовых результатов. Суть и управление качеством кредитного портфеля. Характеристика кредитной деятельности.
отчет по практике [262,0 K], добавлен 06.09.2015Место банковского кредита в совокупности форм кредита. Понятие, роль и принципы формирования кредитного портфеля. Условия диверсифицированности кредитных портфелей коммерческих банков РФ. Проблемы управления качеством кредитного портфеля банков.
курсовая работа [297,5 K], добавлен 26.05.2013Технологии продаж розничных банковских продуктов Российской Федерации. Обзор банковских продуктов (как для частных лиц и для юридических лиц). Удовлетворение потребностей клиентов с целью получения прибыли. Оценка качества сервиса приема платежей.
дипломная работа [37,3 K], добавлен 01.09.2014Место и роль финансового менеджмента в коммерческом банке. Применение прогнозирования поддержки управленческих решений. Анализ финансовых показателей АКБ "Инвестторгбанк", оценка затрат. Себестоимость банковских продуктов и услуг, их формирование.
дипломная работа [594,9 K], добавлен 13.01.2011Сущность, классификация и характеристика основных активных операций коммерческого банка. Методы управления качеством банковских активов и принципы кредитования. Анализ и оценка активов банка с точки зрения их ликвидности на примере ОАО "Запсибкомбанк".
курсовая работа [30,6 K], добавлен 15.09.2009Сущность банковского менеджмента. Контроль банковской деятельности. Анализ управления персоналом. Эффективность менеджмента в банке. Направления совершенствования менеджмента в Набережночелнинском отделении Сбербанка РФ. Оценка положения банка на рынке.
курсовая работа [50,6 K], добавлен 14.12.2013
