Пробные занятия. Бесплатно!
Приглашаем всех желающих посетить бесплатные пробные занятия по курсам МВА и профессиональной подготовки. Занятия проходят в реальных группах, никаких постановочных занятий. Ознакомиться с расписанием пробных занятий, выбрать заинтересовавшее и зарегистрироваться на него можно здесь


Формирование требований к системе электронного документооборота в компании-дистрибьюторе



Зарницын К.М.
выпускник группы MBA CIO-20
Школа IT-менеджмента
АНХ при Правительстве РФ


Введение

Основная цель аттестационной работы – формирование требований к системе электронного документооборота (СЭД) компании. Объектом исследования выступает компания General Accessories. Предметом исследования выступают, в первую очередь, бизнес-процесс продажи комплектующих клиентам, наиболее наглядно демонстрирующий недостатки существующей системы электронного документооборота. Во вторую очередь, модель ведения переговоров с клиентами/поставщиками, указывающая на отсутствие единой системы ведения истории взаимоотношений с клиентом, т.е., так называемой, CRM-системы.

В работе решаются следующие задачи:

  1. Описание и моделирование бизнес-процесса продажи комплектующих
  2. Описание модели ведения переговоров
  3. Обзор существующих СЭД на платформе Lotus
  4. Формирование требований к СЭД

Компания General Accessories образована в 1994 году и начиная с 2003 года проводит агрессивную региональную экспансию. В этой связи компания столкнулась с рядом проблем:

  1. Так как бизнес компании начал переживать бурный рост, то это привело к увеличению документооборота компании. В связи с тем, что основной бизнес компании оптовая продажа автомобильных зап. частей, больше всего увеличился документооборот, связанный с провозными документами. Возросла потеря документов и очень сложно стало отследить всю цепочку перемещения документов. У людей стало больше времени уходить на то, чтобы отследить историю перемещения документа, стало генерироваться множество побочных действий, связанных с тем, чтобы составить единый реестр документооборота провозных документов. В результате документы теряются или приходят дважды, что сказывается на дальнейшей работе с клиентами в не лучшую сторону.
  2. В связи с тем же бурным ростом бизнеса компании образовалась еще одна проблема – усложнился процесс отслеживания взаимоотношений с клиентами/поставщиками компании. Эта проблема заключается в том, что менеджеры по закупкам и менеджеры по продажам общаются со своими партнерами различными способами (e-mail, icq, skype, msn и т.д.). Из-за этого стало сложнее отследить историю взаимоотношений и принимать управленческие решения.

Понимая важность обрисованных проблем, руководство компании поручило отделу ИТ предоставить рекомендации по их решению. Данная работа отражает те предложения, которые были сформированы отделом.

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

Компания – объект исследования

Как было сказано выше, компания General Accessories была основана в 1994 году. Поначалу это был один офис в Москве с несколькими сотрудниками, которые занимались закупкой зап. частей и их розничной продажей. Компании не без труда удалось преодолеть дефолт 1998-го года. Но с началом нового тысячелетия дела компании пошли очень хорошо и, уже в 2001 году, компания вышла на региональный рынок РФ и открыла торговые представительства в Санкт-Петербурге и Новосибирске. К 2004 году компания открыла еще 3 представительства в РФ: в Казани, Екатеринбурге, Ростове-на-Дону и вышла на рынок СНГ, открыв представительство в Киеве. К 2008-му году представительство компании возросло до 9 регионов в РФ, трех стран СНГ, двух стран Дальнего Зарубежья, были открыты четыре склада в ближнем Подмосковье и два буферных склада в Дальнем Зарубежье. В связи с кризисом 2008-2009 гг. бизнес компании немного сократился, как и её представительство. Но, на момент написания аттестационной работы, компания практически восстановила свой оборот и начала экспансию в страны Восточной Европы и Ближнего Востока, где были открыты 3 представительства компании.

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

За пределами головного офиса основной является матричная структура. Например, отделы информационных технологий подчиняются Генеральному директору соответствующей компании и Директору Информационных Технологий головного офиса.

Основные показатели деятельности компании:

  • Годовой оборот – 30 млн. $
  • 8 представительств в РФ
  • 6 представительств в странах Ближнего и Дальнего Зарубежья
  • Покупатели в 15 странах
  • 1000 сотрудников

Бизнес-проблемы

В компании порождается огромное число провозных документов, связанных с процессом продажи комплектующих. Например, количество документов за 2008 год составило примерно 15 тысяч, за 2009 – 20 тысяч, за первое полугодие 2010 года 11 тысяч документов. Сюда входят такие документы как, товарно-транспортные накладные, спецификации, листы сборки, ТОРГ13, накладные на расход, гарантийные талоны и т.п. И это только по деятельности главного офиса, если же брать в расчет все представительства компании вместе, то количество документов утраивается. В связи с этим возрастает сложность проследить полный цикл жизни документа, от его создания, до того момента, когда он отправляется в архив бухгалтерии. Также из-за отсутствия единой системы учета документов возрастает количество утерянных документов. Например, в 2009 году было утеряно 10% провозных документов, которые должны были вернуться от клиента в компанию, а за первое полугодие 2010 года – 9%. Причин, по которым теряются документы большое количество, но основной из них является человеческий фактор.

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

По проведенным опросам и исследованиям удалось выяснить, что сотрудники отдела продаж (в частности, помощники менеджеров) тратят на внесение информации в реестр по документам своего отдела в среднем по 8 минут на один пакет документов. Количество пакетов документов за день может достигать 30-40 штук. Таким образом, получаем, что помощник тратит в среднем 3 часа своего рабочего времени на данную операцию. Сотрудник бухгалтерии тратит в среднем 3,5 часа своего рабочего времени ежедневно на те же операции, что и сотрудник отдела продаж, но только информация вносится в реестр собственного отдела.

Было принято решение ввести следующие метрики для вышеописанного бизнес-процесса, которые необходимо будет улучшить при помощи внедрения СЭД:
1. Время, затрачиваемое сотрудниками на операции описанные выше. Данная метрика будет измеряться в человеко-часах.
2. Количество потерянных документов. Эта метрика будет измеряться в процентах от общего количества документов.

Еще один очень важный момент, который руководство хотело бы улучшить при помощи внедрения СЭД – ведение истории взаимоотношения с клиентами/поставщиками. Дело в том, что за каждым менеджером по продажам/ по закупкам закреплены свои клиенты/поставщики. Каждый менеджер ведет переписку с партнером, используя всевозможные виды общения, доступные в наше время. Это и e-mail, и icq, и MSN, и Skype. При этом история общения с партнером представляет собой не очень удобоваримый вид для поиска, анализа и принятия управленческих решений. В связи с этим встал вопрос, каким образом можно эту информацию структурировать и привести к нормальному виду.

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

В итоге мы имеем следующее, существующие бизнес-приложения не удовлетворяют новым требованиям руководства:
1. Нет СЭД, позволяющей более гибко управлять жизненным циклом документов, рабочим временем сотрудников
2. Нет глобальной системы управления историей взаимоотношений с клиентами, которая позволяла бы более гибко принимать управленческие решения в отношении клиентов и более детально и быстро просматривать историю взаимоотношений
3. Нет системы управления проектами, а, значит, нет возможности в полной мере осуществлять данное управление

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

Выводы

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

  1. При описании и моделировании бизнес-процесса продажи комплектующих были выявлены существенные недостатки существующей системы документооборота. Они указывают на то, что сотрудники компании чрезмерно расходуют своё рабочее время на решение однотипных, повторяющихся задач при работе с документами. Были сделаны выводы о том, что необходимо внедрение системы, которая позволит существенно сократить затрачиваемое время на эти задачи сотрудниками. Также была выявлена проблема, которая заключается в том, что большая часть потери документов происходит из-за несовершенности методов учета печатаемых документов. Был сделан вывод о том, что во внедряемой системе должна быть возможность одновременной работы для нескольких сотрудников с одним и тем же документом. Это, по мнению большинства, должно помочь сократить потерю документов и устранить несостыковки в единых реестрах по учету документов различных отделов.
  2. При описании модели ведения переговоров также были выявлены существенные недостатки существующей системы ведения переговоров. Эти недостатки заключаются в том, информация по клиентам/поставщикам хранится в разрозненном виде и не представляет собой единого целого, что существенно затрудняет работу с контрагентом, либо же передачу того или иного контрагента другому сотруднику, в случае каких-то вынужденных обстоятельств. Были сделаны выводы о том, что необходимо внедрение кардинально новой системы, которая позволит существенно улучшить систему взаимоотношений и сократить временные затраты на принятие управленческих решений. В связи с этим были сформированы функциональные требования, перечисленные в предыдущей главе.
  3. В ходе изучения материала по существующим системам, консультаций с производителями данных систем, были сделаны следующие выводы. Во-первых, готовые продукты стоят больших денег, во-вторых, зачастую готовый продукт очень ограничен в плане различных доработок, т.к. доработки ведут за собой временные затраты на формирование требований на изменения, согласование с производителем временных ограничений на разработку этих изменений, их последующего внедрения, что является очень важным для учредителя компании. В связи с этим было принято решение о формировании требований к системе, которые были описаны в предыдущей главе, и разработке системы с «нуля».
  4. В ходе решения последней задачи данной работы, были сформированы требования, которые были разделены на общие положения, функциональные и технические требования. В общих положениях был изложен взгляд на систему в целом, т.е. общие требования к структуре системы, эргономике, квалификации персонала, к сохранности информации и т.п. В функциональных требованиях перечислены те особенности, которые необходимо разрабатывать. Здесь, опять же, говорится о том, какие моменты необходимо реализовать/разработать при внедрении системы, которые помогут решить существующие проблемы в компании. В технических требованиях описаны особенности системы, которые должны быть реализованы для взаимодействия с существующей ИТ-инфраструктурой компании.

Copyright © 2010 Зарницын К.М.

К оглавлению >>

Группа: 
MBA CIO, осень 2010
Рубрика: 
Корпоративные системы управления
Автор: 
Зарницын К.М.
Голосов пока нет
Школа IT-менеджмента Экономического факультета АНХ, 119571, Россия, г. Москва, проспект Вернадского, д. 82 корп. 2, офис 207, тел.: +7 (495) 933-96-00, Copyright @ 2008-2009