4.1Практический раздел.

Сценарии работ по сопровождению

Как должно быть

Рассмотрим обычный сценарий работы с требованиями к программному продукту. Например, у пользователя возникла проблема. Он звонит по телефону или пишет письмо по электронной почте в службу сопровождения и сообщает о ней. Назовем это письмо «Требованием», оно должно быть зарегистрировано, пользователю сообщается код регистрации. Далее это требование должно быть передано экспертам для анализа. В случае, если есть возможность решить проблему «мирным» путем, то есть данное требование не порождает задач разработки программного кода или дополнительных регламентов, проблема может быть решена путем краткой консультации для пользователя. Данная консультация в письменном виде, факсом или по электронной почте предоставляется пользователю и требование закрывается. В противном случае руководитель службы сопровождения определяет трудоемкость и техническую возможность исполнения данных работ. Координационный совет осуществляет определение бюджета реализации и приоритетов реализации данного требования. Далее к данному требованию формируются задачи, определяются исполнители, устанавливаются планы и т.д.

Как часто бывает

Обычная картина для неформализованного процесса сопровождения — специалист по системе затрачивает значительную часть своего рабочего времени на общение с пользователями по телефону, на разъяснение вопросов, касающихся эксплуатации ПО. При этом поступающая информация в лучшем случае фиксируется в Excel-файле и по мере внесения исправлений удаляется, а в худшем — вообще записывается на клочках бумаги, периодически куда-то пропадающих.

Налицо непродуктивная трата времени квалифицированного специалиста; вдобавок к этому возникают трудности с планированием работ по устранению замечаний. У руководителя нет полной информации по выявленным дефектам, нет сводной статистики по замечаниям, которые уже исправлены или еще нуждаются в рассмотрении.

Кто в подобных случаях расставляет приоритеты? Сам специалист сопровождения — он принимает требования и решает, что делать в первую очередь, а что отодвинуть на потом. Это должен быть чрезвычайно ответственный человек, который болеет за свое дело и аккуратно складывает распечатки дефектов в папочку, а таких среди программистов, в массе своей — приверженцев разумного хаоса, еще нужно поискать. В течение года такой разработчик забивает бумагами ящики своего рабочего стола, и гарантии, что хотя бы одно замечание пользователя при этом не потеряется, — никакой.

Но на самом деле это полбеды, настоящая беда случится, когда этот специалист придет к своему начальнику и скажет, что хочет от этой жизни чего-то большого и светлого, и в его жизненные планы никоим образом не входило просиживание штанов в попытках объяснить «тупому» пользователю, кто есть кто. И, либо его должны оградить от пользователей, либо он найдет себе новую творческую работу. А при текущем состоянии рынка труда действительно найдет, не сильно утруждая себя, и при этом еще и на более высокую зарплату. А теперь представьте себе, как новый сотрудник остается один на один с системой, с пользователями и бардаком, оставленным предшественником. Сколько у него уйдет времени на разбор ситуации и на какое время ваша корпоративная система останется без сопровождения вообще и без качественного сопровождения, в частности?

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

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

Управление требованиями в программном продукте Управление внедрением и сопровождением

Модель управления требованиями, автоматизирующая следующий бизнес-процесс:

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

Документирование подлежащих исполнению работ происходит на уровне связки «Задачи» с объектами метаданных.

Данный подход позволяет сформировать следующую цепочку данных:

Такая информация, размещенная в базе данных, не обременяет пользователей — в большинстве случаев пользователю все равно приходится писать письмо на электронную почту — она не обременяет разработчиков, — они все равно делают отчет о своей работе. Но при этом данный инструмент позволяет получить информацию о всех работах по объекту метаданных, в частности, для кого это делалось, зачем и кто это делал, — что является бесценной информацией для анализа произведенных в системе изменений.

Не менее важным фактором является экономическая оценка требований пользователей через сопоставление трудозатраты ИТ-подразделения и эффективности результата. В целом любую функцию автоматизации управления можно всегда проанализировать по следующим показателям:

• Количество операций в месяц

• Трудоемкость исполнения без автоматизации

• Стоимость исполнения функции без автоматизации (рассчитывается как трудоемкость × количество × ставка исполнителя)

• Трудоемкость исполнения с автоматизацией

• Стоимость исполнения с автоматизацией (рассчитывается как трудоемкость × количество × ставка исполнителя)

• Экономия на автоматизации

• Затраты на автоматизацию (трудоемкость реализации × ставку исполнителя)

• Значимость человеческого фактора (определяет коэффициент, повышающий значимость автоматизации в связи с возможными ошибками оператора при неавтоматизированной подготовке информации)

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

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

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

Для того, чтобы автоматизировать бизнес-процесс нужно иметь его описание, нужно представлять себе объект, который необходимо автоматизировать. Описание бизнеса, описание бизнес-процессов - это важная и самостоятельная задача и решают ее не автоматизаторы и не программисты, а бизнес-аналитики, менеджеры. Они создают модель бизнеса, на детальном уровне которой описываются схемы автоматизируемых бизнес-процессов. Автоматизировать можно только ту схему, которая прошла логический контроль со стороны менеджеров и бизнес-аналитиков. Но возникает проблема, что менеджеры и бизнес-аналитики плохо понимают языки автоматизации исполняемых бизнес-процессов класса BPM.

Инструменты для описания бизнес-процессов - инструменты класса BPA (Business Process Analysis). Например, Oracle BPA (ARIS), Casewise Corporate Modeler, IDEF**, Proforma и др. создают понятные для менеджеров картинки и диаграммы, но для ИТ-специалиста они не всегда пригодны. ИТ-специалисты должны получать, четкое, понятное описание бизнеса, а не создавать его заново, используя свои инструменты, инструменты автоматизации.

Таким образом, необходима связка между инструментами описания бизнес-процессов и инструментами автоматизации бизнес-процессов класса BPM (Business Process Management) такими как Oracle Business Studio (ранее BEA Business Studio), Tibco, Lombardi и др. Этой проблеме и посвящена данная статья

Организация - как система

Любую организацию можно рассматривать как достаточно сложную систему состоящую из множества подсистем и элементов. Достаточно точное определение системы дается в стандарте ИСО/МЭК 15288:2002 - "Проектирование систем - Процессы жизненного цикла системы".

Система [system] - комбинация взаимодействующих элементов, организованных для того, чтобы достичь одну или более заявленную цель. [1] То есть, для описания системы необходимо определить элементы (объекты) из которых состоит система и связи между этими элементами (объектами). Для практических нужд моделирования бизнес-процессов связи между элементами системы могут иметь различный характер, свойства и атрибуты, то есть тоже могут рассматриваться как объекты системы.

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

Одной из лучших работ, затрагивающей проблемы классификации объектов в сложных системах является книга Гради Буча [2], посвященная объектно-ориентированному программированию. Всем бизнес-аналитикам можно порекомендовать найти и прочитать эту книгу, абстрагируясь от того, что она написана программистом для программистов. Поскольку проектирование сложного программного обеспечения весьма сходно по характеру с проектированием систем менеджмента, нам будет весьма уместно воспользоваться наработками Гради Буча и его ссылками на наработки других специалистов, приведенными в этой книге. Воспользуемся же этими наработками в готовом виде.

Поскольку с термином "система" мы уже определились, можно процитировать первые два из пяти признаков сложной системы из книги Гради Буча:

1. Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровня.

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

Если говорить об отдельных бизнес-процессах, то здесь очень важно вовремя остановиться при проведении декомпозиции бизнес-процессов сверху-вниз. На практике, для того чтобы достаточно четко разделить объекты моделирования по их основным атрибутам в базе объектов в компании ООО "ФОРС-Центр разработки" используется широко распространенная Матрица Захмана [3].

Матрица Захмана - схема для структурирования бизнес-процессов/p>

Рис. 1. Матрица Захмана - основа для анализа и структурирования бизнес-процессов.

Матрица Захмана (framework) определяет какие аспекты деятельности организации:

• Цели - Зачем?

• Процессы- Как?

• Структуры - Кто?

• и т.д.

… и на каких уровнях:

• Контекстуальном - Миссия / Стратегия

• Концептуальном - Бизнес / Организация

• Логическом - Подразделения / Специализация

• и т.д

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

2. Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя./i>

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

Рецептов от подобного "произвола" есть только два:    а) Тщательно продумать, сформулировать и утвердить цель проекта описания процессов.    б) Не менее тщательно продумать, сформулировать и утвердить Соглашение по моделированию, в котором должно быть максимально четко определено: Какие объекты можно включать в модель бизнес-процесса? Какими свойствами должны обладать объекты, чтобы их можно было включить в модель?

Нотация для бизнес-процессов

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

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

Рис. 2 Так выглядит модель бизнес-процесса "Отчета за командировку" на детальном уровне описания в средстве бизнес-моделирования (Сasewise Corporate Modeler).

С другой стороны, стандартом де-факто нотации, используемой в BPM-инструментах стал язык BPMN (Business Process Modelling Notation).

Нотация BPMN может использоваться при описании бизнес-процессов на технологическом уровне описания бизнеса, однако это скорее исключение из правил, так как бизнес-аналитики предпочитают работать с более простыми нотациями. Возникает разрыв между языками, на которых говорят бизнес-аналитики и программисты.

Объекты определили, нотацию выбрали, модель нарисовали. Что дальше?

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

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

Такой транслятор "BPM Accelerator" был разработан в компании ФОРС

BPM Accelerator реализован как встроенный модуль Casewise Corporate Modeler.

Рис. 3 Схема преобразования диаграммы бизнес-процесса (нотация Casewise) с помощью транслятора в исполняемый процесс BPM.

После его запуска для выбранной диаграмма, сначала проверяется соответствие нотации, используемой при построении данной диаграммы, нотации BPMN и в случае необходимости предлагается дополнить таблицу соответствия между используемыми нотационными объектами и объектами из нотации BPMN. То есть бизнес-процесс проходит дополнительную проверку на непротиворечивость созданных объектов и связей между ними. После установления соответствия осуществляется трансляция диаграммы в код на промежуточном языке XPDL (Extended Process Definition Language), который уже загружается в BPM-инструмент.

Наш инструмент BPM Accelerator позволяет осуществить трансляцию детальных диаграмм из средства бизнес-моделирования в средство автоматизации бизнес-процессов.

Пример результата трансляции диаграммы бизнес-процесса "Отчет за командировку" в среду Oracle BPM Studio показан на следующем Рис.4.

Рис. 4 Так выглядит модель бизнес-процесса "Отчет за командировку" после трансляции ее в BPM.

При таком подходе описание автоматизируемого бизнес-процесса не вырывается из контекста описания бизнеса организации в целом. Это описание бизнес-процесса, которое может быть и в другой нотации, уже имеется в средстве BPA и, что самое важное, оно было создано исходя из целей организации (первый столбец матрицы Захмана) с последовательной детализацией, уточнением основных процессов организации и согласовано с описаниями других аспектов бизнеса (организационной структурой, данными, местоположениями и т.д.). В средствах BPA модель бизнес-процесса была проверена на связность, непротиворечивость и одобрена бизнес-аналитиками и менеджерами.

Таким образом, для автоматизации конкретного бизнес-процесса не нужно повторять его описание в средстве BPM, в которое транслируется готовая модель.

Заключение

Актуальность темы «Виды и учет удержаний из заработной платы» не вызывает

сомнения, так как является очень важной составной частью всего бухгалтерского

учета, работы с сотрудниками и налоговых начислений. Кроме того ее актуальность

связана и с появлением нового Трудового Кодекса, а также внесенных изменений в

Налоговый Кодекс.

Новым ТК предусмотрены меры защиты сотрудника от неправильных удержаний из

заработной платы. Отсюда следует важный вывод: любые удержания возможны

только тогда, когда это прямо указано в ТК РФ (ст.137). Это означает, что случаиудержаний из заработной платы не могут быть установлены ни подзаконными

правовыми актами федеральных органов власти, ни законодательством субъектов

РФ.

Однако общий перечень удержаний, предусмотренный в ч.2 ст. 137 ТК РФ ограничен

лишь случаями удержаний по инициативе работодателя и в этом смысле не

является исчерпывающим. При производстве удержаний из заработной платы

необходимо руководствоваться так же Гражданским кодексом РФ, Налоговым

кодексом РФ, Кодексом об административных правонарушениях РФ, Уголовно-

исполнительным кодексом РФ, Семейным кодексом РФ.

Рассмотрение в суде дел о нарушениях при удержании из заработной платы

представляет немалую сложность в связи со вступлением в силу ТК РФ, а так же

отсутствием руководящих указаний Верховного Суда РФ по применению норм этого

кодифицированного закона о труде, касающихся регулирования отношений по

материальной ответственности работников перед работодателем. Кроме этого, с

принятием Конституции РФ и на ее основе ряда федеральных законов,

регулирующих трудовые отношения, возникает немало проблем в плане

соотношения прав человека, гарантий права собственности и осуществления

предпринимательской деятельности.

В современных условиях предприятиям и организациям необходимо постоянно

повышать уровень бухгалтерского учета и отчетности. Этого можно достигнуть,

прежде всего, периодическим повышением квалификации работников

бухгалтерского учета.

Переход бухгалтерского учета на автоматизированную основу позволит не только

облегчить труд работников бухгалтерии, но и значительно повысить

производительность их труда, что положительным образом отразится на

деятельности предприятия.

Данная работа имела своей целью рассмотрение учета труда, заработной платы и

расчетов с рабочими и служащими на предприятиях промышленности,

строительства и торговли.

Переход бухгалтерского учета на автоматизированную основу позволит не только

облегчить труд работников бухгалтерии, но и значительно повысить

производительность их труда, что положительным образом отразится на

деятельности предприятия.

В данной курсовой работе подробно определены и проанализированы сущность и

видов удержаний из заработной платы; ознакомились с составом первичных

документов и регистров по учету удержаний оплате труда, уделили внимание учету

удержаний и из заработной платы работников, а также их отражению на счетах

бухгалтерского учета.

Список литературы

1. Налоговый кодекс РФ. Часть 1 и 2.

2. Федеральный закон «О бухгалтерском учете» № 123-ФЗ от 23.07. 1998г.

3. План счетов бухгалтерского учета и финансово-хозяйственной деятельности

организации и инструкции по его применению. Приказ Минфина № 94н от 31 октября

2000г.

4. Комментарии к новому Плану счетов бухгалтерского учета / Под ред. А.С. Бакаева. - М.,2001

5. Методические указания МФ РФ по бухгалтерскому учету и отчетности (2003 - 2005гг).

6. Бухгалтерский учет. Учебник /Под ред. П.С. Безруких. - М.: Бухгалтерский учет, 2002. -

528.

7. Бухгалтерский учет. Экспресс-курс. - М.: ИНФРА-М, 2001 .

8. Васькин Ф.И., Свободина М.В. Теория бухгалтерского учета - М.: Колос, 2000. - 208с.

9. Камышанов П.И. Практическое пособие по бухгалтерскому учету. - М.: Экономика,

2003 .

10. Козлова Е.П., и др. Бухгалтерский учет - М.: Финансы и статистика, 2004. - 464с.

11. Кондраков Н.П. Бухгалтерский учет : учебное пособие для ВУЗов - М.: ЮНИТИ, 2000.

- 560с.

12. Кондраков Н.П. Бухгалтерский учет: Учеб. пособие. - М.: «Информационное агентство

«ИПБ-БИНФА», 2002.

13. Кожинов В.Я. Бухгалтерский учет. Пособие для начинающих. - М.: Федеральная

Книготорговая Компания, 2001. - 256с.

14. Климова М.А. Документооборот в бухгалтерском учете - М.: Издательство «Налоговый

вестник», 2002.

15. Лисович Г.М., Ткаченко И.Ю. Бухгалтерский управленческий учет. - Ростов н/Д:

издательский центр «Март», 2004. - 354с.

16. Макальская М.Л., Денисов А.Ю. Самоучитель по бухгалтерскому учету - М.: АО

«ДИС», 2004.

17. Палий В.Ф. Бухгалтерский учет. - М.: Информационное агентство «ИПБ - БИНФА»,

2005. - 336с.

18. Федотов А.В. Бухгалтерский учет в торговле: теория и практика. - М.: ИНФРА-М,

2001. - 318 с.

19. Щадилова С.Н. Основы бухгалтерского учета: Учеб. Пособие. - М.: ИКЦ «ДИС», 2004.

20. Алиев Б.Х., Абдулгалимов А.Н. Теоретические основы налогообложения: Учеб.

пособие для вузов / Б.Х. Алиев. - М.: ЮНИТИ - ДАНА, 2004. -159 с.

21. Аткинсон Э.Б., Стиглиц Д.Э. "Лекции по экономической теории государственного

сектора", М., "Аспект-Пресс", 2003

22. Блинов М.В. Бюджетная реформа в РФ и Бюджетный кодекс РФ. Налоговый вестник

М., №11 2004 г.

23. Гажиев Г.А. Предприниматель. Налогоплательщик. Государство/ ГА. Гаджиев, С.Г

Пепеляв. М.: ФБК - Пресс, 2003 .221 с.

24. Галимзянов Р.Ф. Общие принципы минимизации налогов//Налоги и платежи - 2005. -

№6. - с. 45.

25. Лукаш А.Ю. Бухгалтерский и налоговый учет различных хозяйственных операций. М.,

Экспо, 2004, 454 с.

26. Медведев А.Н. Как планировать налоговые платежи. Практическое руководство для

предпринимателей. - М.: ИНФРА-М, 2005, 364 с.

27. Налоги и налогообложение: Учеб. пособие \Под ред. Русаковой И.Г., Кашина В.А..-

М.:ЮНИТИ, 2005.

28. Налоговая нагрузка//РосБизнесКонсалтинг

29. Пансков В.Г. Налоги и налогообложение: Учеб. для вузов / В.Г. Пансков, В.Г. Князев. -

М.:МЦФЭР, 2003.-336 с.

30. Романова Т.В. Первичные документы и действующее законодательство Российской

Федерации. - М.: Статус-кво, 2005