8 Проектирование
реклама
[МИНОБРНАУКИ РОССИИ ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «НОВОСИБИРСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ» (НОВОСИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ, НГУ) ____________________________________________________________________________________________________________________ Отчёт по курсовой работе на тему Разработка системы управления малым предприятием на основе организации компонент Выполнил: Елисафенко М. Е. гр. 12226 Руководитель: Васючкова Т. С. к.ф.-м.н., доцент Новосибирск, 2013 г. Содержание ВВЕДЕНИЕ .................................................................................................................. 4 1 Обзор предметной области. ..................................................................................... 6 2 Обзор аналогов. ...................................................................................................... 13 3 Объект исследования.............................................................................................. 18 4 Предыдущая работа ................................................................................................ 21 5 Границы исследования ........................................................................................... 24 5.1 Минимальная система ..................................................................................... 24 5.2 Максимальная система .................................................................................... 28 6 Постановка задачи .................................................................................................. 30 7 Формальная постановка задачи ............................................................................ 31 8 Проектирование ...................................................................................................... 32 8.1 Общий подход к проектированию системы .................................................. 32 8.2 Компоненты ...................................................................................................... 33 8.3 Формальное определение компонент ............................................................. 35 8.4 Подсистемы ....................................................................................................... 37 8.5 Архитектура ...................................................................................................... 37 8.6 Модуль «Деятельность» .................................................................................. 38 8.7 Модуль «Кадры» ............................................................................................... 40 8.8 Модуль «Клиенты» ........................................................................................... 41 8.9 Модуль «Настройки» ....................................................................................... 41 8.10 Модуль «Товары» ........................................................................................... 42 8.11 Модуль «Конфигуратор системы» ................................................................ 42 9 Реализация ............................................................................................................... 44 9.1 Система.............................................................................................................. 44 9.2 Интерфейс ......................................................................................................... 46 Заключение ................................................................................................................. 49 Список использованных источников ....................................................................... 50 2 Список запланированных публикаций .................................................................... 51 Приложение ................................................................................................................ 52 3 ВВЕДЕНИЕ Вопросы о том, как эффективно управлять предприятием существуют давно. Поэтому было придумано множество методологий и стандартов оптимального управления. Однако многие из этих стандартов рассчитаны на управление крупными компаниями [1]. И это порождает вопрос о том, что же делать малым и средним предприятиям? Несмотря на то, что в небольших компаниях работает на порядок меньше людей, чем в крупных, проблемы управления всё-таки возникают. Задачи учёта и отчётности уже хорошо изучены и существует много систем, которые позволяют эти задачи решать. Поэтому особенно ярко проблемы управления выражены в бизнесе, который ведётся преимущественно в проектной форме. В данной работе будут рассмотрены проблемы малых предприятий и решение этих проблем при помощи автоматизированных систем на примере сувенирного бизнеса. Особенностью рассматриваемого бизнеса является то, что он осуществляется по схеме B2B (Business to Business), т.е. когда клиентами компании являются другие компании (юридические лица). При написании данной работы использованы результаты, полученные в предыдущей работе по разработке иерархического планировщика задач. В ходе разработки такого планировщика была предпринята попытка создать конструктор системы управления предприятием. Основная идея заключалась в том, что система управления предприятия состоит из слабо зависимых модулей, которые можно проектировать по мере необходимости в нужной конфигурации, ведь ничто так не мешает работе, как ненужные функции. Задачей являлась разработка сервиса, который поможет проектировать эти модули системы по частям, т.е. настраивать систему под конкретный бизнес. Посылом к разработке такой системы стало осознание того, что невозможно создать какую-то универсальную систему, которая была бы одинаково удобна для всех. Проектный бизнес во многом схож для различных видов деятельности, тем не менее, в каждом виде деятельности есть свои понятия, которые используются только в этой конкретной деятельности. В начале работы производится обзор предметной области и стандартов управления с целью выяснения актуальности проблемы и её месте в управлении предприятиями. Затем оцениваются сильные и слабые стороны конкурентоспособных систем управления, при обзоре аналогов разрабатываемой системы. Так же производится обзор существующей системы ГЛОСИС управления компании «Кьюти-дизайн» исходя из того что в ней могут быть заложены хорошие, проверенные временем решения. В основной части 4 много внимания уделяется определению объекта исследования на основании различных практик управления предприятиями [1-4]. Из определения объекта исследования становятся понятными границы исследования и набор базовых модулей при проектировании. При проектировании системы исследуются методы работы с иерархическими структурами и их применение в системе управления предприятием. 5 1 Обзор предметной области. Мировой опыт развития малого предпринимательства свидетельствует о его большом потенциале и ряде преимуществ перед средним и крупным бизнесом. Становление и развитие малых предприятий не требует значительных финансовых ресурсов, а сочетание небольших размеров фирм с их производственной и управленческой мобильностью позволяет чутко реагировать на постоянно меняющуюся конъюнктуру рынка.[5] В настоящее время использование информационных технологий в управлении малым бизнесом - объективная необходимость. Они стали одним из общепринятых инструментов контроля хозяйственной деятельности, повышения рентабельности и успешного противостояния в конкурентной борьбе. Их главное предназначение - построение информационного пространства малого предприятия, позволяющее отображать состояние бизнеспроцессов в управленческой, бухгалтерской и административной системах управления организацией. [6] В рамках предыдущей работы был создан каркас конструктора системы управления, и при помощи него были разработаны несколько модулей различного характера: Модули, которые могли взаимодействовать с существующей системой управления предприятия. Совершенно новые самостоятельно работающие модули. Вскоре возник вопрос о том, что существующая система управления предприятием ГЛОСИС устарела и её нужно переделывать, но как? Была предпринята попытка спроектировать систему по концепции складов, согласно которой каждый модуль представляет собой склад, в котором что-то лежит — деньги, материалы, товары и т.д. Тогда суть системы состоит в том, чтобы правильно перемещать товары по складам. Но в этом случае не совсем понятно, как, например, отслеживать ход работ и решать другие управленческие задачи, поэтому предложенная концепция была отклонена, но породила ряд вопросов: Кому нужна разрабатываемая система? Какие проблемы она должна решать? Нет ли других систем, которые могут решать эти проблемы? Какие функции должна выполнять такая система? Ответы на первые три вопроса на данный момент найдены. Разрабатываемая система нацелена на руководителей бизнеса, ведущегося в проектной форме и имеющем в штате до 100 человек. В первую очередь, это 6 сувенирный бизнес, т.к. система разрабатывается для сувенирной компании, которая имеет в ней необходимость. Так же заинтересованность в такой системе высказывают руководители других сувенирных компаний-партнёров. Помимо сувенирного бизнеса это может быть разработка веб-сайтов, рекламный бизнес, разработка компьютерных игр, изготовление тортов и т.д. То есть для любого вида бизнеса, где продукт изготавливается преимущественно под заказ. Проблемы, которые должна решать разрабатываемая система следуют из того, на кого она нацелена. Как правило, малый бизнес не становится сразу средним или крупным, т.е. процесс расширения бизнеса происходит постепенно. Сперва в бизнесе может участвовать 5-10 человек, и в этом случае пока не нужны системы управления. Но когда бизнес начинает расширяться и в компании работает уже больше 10 человек, то появляются проблемы, связанные с задачами управления, становлением и развитием информационноуправленческих потоков: Непрозрачность нижнего уровня при становлении иерархии (появление руководителей второго уровня). Несмотря на то, что руководитель верхнего уровня должен иметь возможность проверять ход работ на любом участке своей компании, при появлении руководителей отделов он начинает во многом полагаться на их отчёты, ведь именно для этого он и назначил руководителей отделов. При этому у руководителя верхнего уровня возможны проблемы различного характера, когда дела на какомлибо участке идут плохо. Например, руководители отделов по каким-либо причинам не предоставляют ему в отчёте достоверную информацию. Поэтому руководитель верхнего уровня должен постоянно иметь доступ к информации о работе любого сотрудника в любом отделе. Принятие решений по рентабельности проектов конкретного типа. Основной акцент делается на результативность предприятия через показатели рентабельности, обеспечиваемые за счет прибыльности продаж и оборачиваемости финансовых активов.[5] Расчет показателей рентабельности основан на соотнесении величины полученной прибыли с размерами выручки, активов и других показателей. Для расчета показателей могут использоваться различные виды прибыли: чистая, налогооблагаемая и прибыль от продаж. В компании, работающей в проектной форме скапливается очень много проектов, при этом некоторые из них похожи друг на друга. В этом случае руководителю необходимо уметь определять, будет ли выгодно браться за очередной проект. При этом руководитель основывается на информации о прибыли и 7 затратах по аналогичным выполненным проектам. Снижение качества управления проектом из-за недостоверности информации о ходе работ. При работе над несколькими проектами тяжело отслеживать проблемы, которые возникают в ходе работ. Руководителю необходимо владеть актуальной информацией и видеть, где возникают проблемы. Представление результатов работы разных отделов в виде удобном для общего анализа деятельности компании. Часто руководители отделов пишут о результатах работы своего отдела как им удобно и где им удобно. Но часто это неудобно для руководителей верхнего уровня, когда руководители разных отделов приносят отчёты в различных формах. Это естественно, т.к. бухгалтер мыслит совершенно не теми категориями, какими мыслит руководитель производства или склада. Соответственно эта информация в таком разнородном виде не поддаётся никакому анализу. Затраты на инструктирование сотрудников. Как правило, чем сложнее система, тем более квалифицированный специалист требуется для того, чтобы научить сотрудников в ней работать. А помимо этого каждого нового сотрудника необходимо инструктировать по работе в компании вообще. Но обучение сотрудников — это время и деньги компании. Для малого бизнеса это может оказаться очень затратным. Поэтому руководители заинтересованы, чтобы сотрудники по возможности сами могли обучиться как минимум основным правилам работы в компании. Обработка отчётов по работе каждого сотрудника. Сотрудники отделов, как и их руководители, имеют привычку отчитываться так как им удобно, а это не правильно с точки зрения их руководителя. Как было сказано выше, чем более унифицирована форма отчёта, тем легче эти отчёты поддаются анализу. Уже существуют системы, решающие данные проблемы, но все они сложны и дороги, т.к. ориентированы на крупный бизнес и не подходят для малых и средних предприятий. Во-первых, средний и малый и бизнес не может себе позволить их приобрести. Во-вторых, много времени и затрат уходит на внедрение этих систем. В третьих, среднему и малому бизнесу зачастую не нужно большинство функций таких систем. Многие функции могут даже мешать ведению бизнеса. Можно было бы попытаться создать систему по частям, где каждая часть представляет собой отдельный веб-сервис, который справляется со своими 8 задачами. Но в этом случае есть большая вероятность представления информации в разнородной форме. А это является одной из тех проблем, которые должна решать разрабатываемая система. Ключевая идея создаваемой системы – сделать её малобюджетной. Она будет доступна малому и среднему бизнесу. Второй ключевой момент – независимость от ОС, т.е. реализация её в виде web-приложения. Система будет разворачиваться на специальном сервере, и сотрудники смогут получать доступ прямо из броузера на своём ПК или мобильном устройстве. Под сервером можно понимать как сервер самой компании-клиента, так и арендованный сервер у компании, предоставляющей хостинг. Теперь, прежде чем поставить задачу, необходимо понять, какие функции должна выполнять разрабатываемая система. Проблемы управления изучаются уже давно и методологии их решения нашли своё отражение в стандартах управления, согласно которым потом реализуются системы управления предприятиями. Ниже перечислены распространённые стандарты управления [1,2,4]: MPS (Master Planning Shedule) – хорошо известная методология "объемнокалендарного планирования". Является базовой практически для всех плановоориентированных методологий. Применяется в основном в производстве, но также может использоваться и в других отраслях бизнеса, например, дистрибуции. MRP (Material Requirements Planning) – Автоматизированное планирование потребности сырья и материалов для производства. Данная методология заключается в определении конечной потребности в ресурсах по данным объемно-календарного плана производства. Концепция MRP легла в основу построения MRP-систем. Главной задачей MRP-систем является обеспечение наличия на складе необходимого количества требуемых материалов/комплектующих в любой момент времени в рамках срока планирования. Программные системы, реализованные на базе MRPметодологии, позволили оптимально регулировать поставки комплектующих продукции для производства, контролировать складские запасы и саму технологию производства. Главное достижение MRP-систем – минимизация издержек, связанных со складскими запасами. CRP (Capacity Requirements Planning) – Планирование производственных ресурсов. Данная концепция схожа с MRP, но вместо единого понятия состава изделия она оперирует такими понятиями, как "обрабатывающий центр", "машина", "рабочие ресурсы", ввиду чего технически реализация CRP более 9 сложна. Обычно применяется совместно с MRP ввиду тесной логической связи при планировании. Методологии MRP/CRP применяются в АСУП производственных предприятий. АСУП (Автоматизированная Система Управления Предприятием) – российский стандарт управления, ориентированный в основном на задачи учёта и генерацию бухгалтерской отчётности. FRP (Finance Requirements Planning) – Планирование финансовых ресурсов. MRPII (Manufacturing Resources Planning) – Планирование и управление всеми производственными ресурсами предприятия: сырьем, материалами, оборудованием, трудозатратами. Планирование производства - интегрированная методология, включающая MRP/CRP и, как правило, MPS и FRP. При использовании данной методологии обязательно подразумевается анализ финансовых результатов производственного плана. Стандарт MRP II делит сферы отдельных функций на два уровня: необходимый и опциональный. Для того, чтобы программное обеспечение было отнесено к классу MRP II, оно должно выполнять определенный объем необходимых функций. ERP (Enterprise Resources Planning) – Управление корпоративными ресурсами. К свойствам MRPII добавилось управление финансовыми ресурсами, маркетинг. ERP концепция – первая направленная на управление бизнесом, а не только производства, как MRP. Под ERP подразумевается "интегрированная" система, выполняющая функции, предусмотренные концепциями MPS-MRP/CRP-FRP. Важным отличием от методологии MRPII является возможность "динамического анализа" и "динамического изменения плана" по всей цепочке планирования. Конкретные возможности методологии ERP существенно зависят от программной реализации. Концепция ERP более "размыта", чем MRPII. Если MRPII имеет явно выраженную направленность на производственные компании, то методология ERP оказывается применимой и в торговле, и в сфере услуг, и в финансовой сфере. Термин ERP может означать не только информационную систему, но и соответствующую методологию управления, реализуемую и поддерживаемую этой информационной системой. Большинство современных ERP-систем построены по модульному принципу, что дает заказчику возможность выбора и внедрения лишь тех модулей, которые ему действительно необходимы. Модули разных ERP-систем могут отличаться как по названиям, так и по содержанию. Тем не менее, есть некоторый набор функций, который может считаться типовым для программных продуктов класса ERP. 10 ERPII (Enterprise Resource and Relationship Processing) – Управление внутренними ресурсами и внешними связями предприятия. Новая ревизия концепции ERP. Можно считать что, ERPII=ERP+CRM+SCM. Пока что данный класс применяется нечасто. Основная идея ERP II заключается в выходе за рамки задач по оптимизации внутренних процессов организации: кроме интеграции таких традиционных для ERP систем областей деятельности предприятия, как управление финансами, бухгалтерский учет, управление продажами и покупками, отношения с дебиторами и кредиторами, управление персоналом, производство, управление запасами, системы класса ERP II позволяют управлять взаимоотношениями с клиентами, цепочками поставок, вести торговлю через Интернет. SCM (Supply Chain Management) – Управление отношениями с поставщиками. Данная концепция придумана для оптимизации управления логистическими цепями и позволяет существенно снизить транспортные и операционные расходы путем оптимального структурирования логистических схем поставок. Концепция SCM поддерживается в большинстве систем ERP- и MRPII-класса. CRM (Customer Relationship Management) – Управление отношениями с заказчиками. Отслеживание истории развития взаимоотношений, координирование многосторонних связей, централизованное управление продажами и клиент-ориентированным маркетингом. CRM подразумевает накопление, обработку и анализ не только финансово-бухгалтерской, но и прочей информации о взаимоотношениях с клиентами. Это способствует повышению производительности менеджеров, улучшает качество обслуживания клиентов и способствует увеличению продаж. CSRP – Customer Synchronized Resource Planning (Планирование ресурсов, синхронизированное с покупателем). Данный стандарт охватывает также и взаимодействие с клиентами: оформление наряд-заказа, техзадание, поддержка заказчика на местах и пр. Таким образом, если MRP, MRP-II, ERP ориентировались на внутреннюю организацию предприятия, то CSRP включил в себя полный цикл от проектирования будущего изделия, с учетом требований заказчика, до гарантийного и сервисного обслуживания после продажи. Основная суть концепции CSRP в том, чтобы включить Заказчика (Клиента, Покупателя и пр.) в систему управления предприятием. То есть не отдел сбыта, а сам покупатель непосредственно размещает заказ на изготовление продукции - соответственно сам несет ответственность за его правильность, сам может отслеживать сроки поставки, производства и пр. При этом предприятие может 11 очень четко отслеживать тенденции спроса и т. д. CSRP переопределяет практику бизнеса, фокусируя ее на рыночной активности, а не на производственной деятельности. Бизнес-процессы синхронизируются с деятельностью покупателей. Выгоды успешного применения CSRP - это повышение качества товаров, снижение времени поставки, повышение ценности продуктов для покупателя и так далее, а в результате этого - снижение производственных издержек, но что более важно, это создание инфраструктуры приспособленной для создания продуктов удовлетворяющих потребности покупателя, улучшение обратной связи с покупателями и обеспечение лучших услуг для покупателей. Это не эффективность производства, которая будет обеспечивать временные конкурентные преимущества, скорее это способность создавать продукты, удовлетворяющие потребности покупателя и лучший сервис. Способность создавать покупательскую ценность приведет к росту доходов и устойчивому конкурентному преимуществу. 12 2 Обзор аналогов. Существуют системы управления, реализующие эти концепции и являющиеся веб-приложениями, но они, как правило, не решают комплексно обозначенные выше проблемы. Зарубежных аналогов достаточно много (например, Ecount), но они рассчитаны именно на зарубежное ведение бизнеса, которое отличается от российского. В России наиболее близким и успешным аналогом является проект «Мегаплан», который позиционирует себя как очень гибкую и настраиваемую web-ERP систему. При сравнении систем будут интересовать следующие критерии: Виды планируемых ресурсов (человекочасы, документы, деньги, товар, материалы) Понятие проекта Компонент каталога/склада и системы управления товарами Компонент учёта клиентов Компонента штатного расписания и управления сотрудниками Модуль для работы с документами Понятный для непосвящённого человека интерфейс Сложность внедрения системы Архитектура и навигация Поддержка клиентов Таблица 1. Сравнение аналогов. Мегаплан Clarizen ERPnext Вид Люди, деньги планируемого ресурса Люди, деньги Люди, задачи, Товары, люди, деньги задачи, деньги Понятие проекта Сделка Уникальное действие во времени Сделка Модуль каталог/склад Обновляемый Нет из файла Есть, Есть, но реализует товары стандарт MRP добавляются вручную. Модуль клиенты Есть + много Нет функций для работы с ними Есть, но мало функционала 13 Bitrix Сделка Есть, причём хорошо проработан Модуль сотрудники Есть штатное расписание Можно прикреплять сотрудников, но нет штатного расписания Есть штатное расписание Есть штатное расписание Модуль документы Нельзя создавать, можно прикреплять Нельзя Можно, но по создавать, зарубежным можно только стандартам прикреплять Интерфейс Удобно и понятно, есть аналог диаграммы Ганта для планирования задач В целом понятно, есть диаграмма Ганта Архитектура Сетевая, небольшая модульность Иерархическая Сетевая, модульность Сетевая модульность Поддержка Есть Есть Есть Можно создавать, но тяжело настраивать. Унифицирован В целом ный, понятный понятный, но многие важные функции неочевидны Внедрение Нет Мегаплан представляет собой хорошую CRM систему[7], ориентированную на работу с клиентами. Плохо развит сервис работы со складом и нет сервиса производства. Продукт может быть предоставлен в трёх версиях: Совсем простой для управления сотрудниками (отчёты, зарплаты, табеля, отпуска, штатное расписание и пр.) Посложнее - добавляется управления задачами Ещё сложнее — добавляется ограниченное управление складами. Каждый из трёх вариантов Мегаплана сопровождается различным набором модулей. Ещё одним несомненным плюсом «Мегаплана» является наличие демонстрационной версии, в которую можно зайти не имея аккаунта, и проверить заявленные функции. 14 Несмотря на свои достоинства, Мегаплан не подходит для нужд компании «Кьюти-дизайн», т. к. эта система ориентирована на клиента, а компании помимо управления персоналом и клиентами, нужны модули учёта и производства. Управление складами очень ограничено тем, что данные обновляются из файла. А для компании «Кьюти-дизайн» важно автоматизация складов, т. к. файлы складов стали настолько большими, что с их обработкой плохо справляются как компьютеры, так и люди. Мегаплан ориентирован на внутреннюю организацию компании, на клиентов и взаимоотношения с ними. И совсем не ориентирован на производство и поставки, что делает его мало пригодным в интересующей предметной области. Clarizen — это распределённый MSProject в web оболочке. Но направлен он скорее на уникальные, разовые проекты. Нет сервиса выписки документов, работы со складами, партнёрами, сотрудниками. А так же нет сервиса анализа проектов в совокупности. Именно по этим причинам данный продукт так же не подходит для нужд компании «Кьюти-дизайн». ERPnext является наиболее близкой системой к тому, что нужно. Все необходимые модули присутствуют. Интерфейсы всех модулей схожи. Как и у Мегаплана имеет демонстрационную версию. Но эта система работает по сетевой архитектуре, когда любые сущности могут быть друг с другом связаны. Такой подход явно запутывает пользователя, т. к. некоторые сущности должны быть иерархически подчинены другим сущностям. Ещё один минус — мало функциональная база клиентов. Битрикс24 - социальный интранет на базе CRM. В нём есть все необходимые для CRM модули, а кроме того небольшое управление товарами, разбитыми на категории. Помимо модуля CRM есть так же социальная составляющая — фотографии, система сообщений, календарное и некалендарное планирование. Но самым интересным в этой системе является создание бизнес-процессов для автоматизации деятельности компании. Имеет очень широкий спектр настроек вплоть до возможности написания PHP-кода. В итоге Битрикс24 можно рассматривать как мощную CRM систему с возможностью автоматизации бизнес-процессов. Но она не подходит для компании «Кьюти-дизайн» в силу своей направленности на продажи и отсутствия проработанной подсистемы складов и товаров. Помимо выше упомянутых систем существуют другие системы, о которых стоит немного сказать. Достаточно распространена 1С бухгалтерия. Система позволяет учитывать финансовые потоки и выписывать документы напрямую из системы. 15 Существенным минусом является привязка к единственной платформе Windows и требование лицензионных версий для клиентских и серверных машин. Помимо этого система 1С представляет собой однобокий взгляд на финансовый учёт и не способна предоставить аналитическую информацию по проектам. Помимо «Мегаплана» модульный подход для расширения бизнеса начала пропагандировать компания IMB. Она предоставляет программу IBM Cognos Express [8] ориентированную на средний бизнес и предусматривая возможность его расширения. Идея заключается в том, что клиенты IBM скачивают сразу настроенную версию программы под конкретный бизнес со всеми необходимыми функциями. По словам IBM, компании среднего размера сразу смогут получать пользу от использования их программы, а затем расширять систему по мере расширения компании. Развёртывание занимает несколько часов. Сомнительное утверждение, учитывая, что установщик Cognos Express требует 2 гигабайта места на жёстком диске. Заявленные функции планирование, генерация отчётов по планам и управление клиентами. То есть по описанию это примерно такая же CRM система, как и «Мегаплан» но только для платформы Windows. Достаточно распространена отечественная система БЭСТ-5/БЭСТ-4+, которая включает те возможности, которые нужны нашей компании (бухгалтерский и налоговый учеты, контроль наличных и безналичных денежных средств, расчет с партнерами и сотрудниками, ведение складского учета, учет имущества, управление закупками и продажами, учет кадров и расчет зарплаты), но не подходит из-за привязанности к конкретной платформе, т.е. для работы этой системы необходимо иметь специальное серверное оборудование.[9] Следует учесть ещё такой аспект, что любое предприятие, которое принимает на вооружение ERP-систему, рискует оказаться в одном из двух крайних состояний. В одном случае руководство может решиться на полную реконструкцию структуры деятельности для наиболее близкого соответствия её правилам, диктуемым ERP-системой. Другой крайностью может стать основательное изменение самой ERP-системы, чтобы её функционирование было согласовано с таким образом деятельности, который уже существует. Первый вариант чреват тем, что инерция сотрудников приведёт к тому, что они будут сопротивляться внедрению системы. Причём сопротивление может принять скрытую пассивную форму, которая, тем не менее, сможет эффективно тормозить эксплуатацию системы. 16 При рассмотрении зарубежных ERP-систем следует учитывать, что условия их создания и внедрения существенно отличаются от отечественной практики бизнеса. Целый комплекс экономических и юридических условий создаёт особую среду деятельности для российского предпринимательства. Внедряемые зарубежные стандарты обязательно должны быть критически оценены с позиций полезности в отечественных условиях. При втором варианте дисбаланса во внедрении ERP-системы, может быть нарушена внутренняя цельность комплекса, которая может привести к ошибкам и сбоям в системе, которые могут быть выявлены только через значительный период эксплуатации. Из всего вышесказанного можно сделать вывод, что для обозначенных проблем управления, системы только учёта (MPS, MRP, MRPII, FRP) недостаточно, т.к. они автоматизируют работу только производства и бухгалтерии. Возможностей системы ERP для сувенирного бизнеса также не хватает, т.к. методология ERP не включает в себя учёт отношений с клиентами. Как уже было отмечено выше, речь идёт о бизнесе B2B, поэтому немаловажным фактором является взаимоотношение с клиентами. То есть необходимо включить в систему элементы методологии CRM. Из всех методологий наиболее близкой по смыслу к решаемой задаче является стандарт управления ERP II. Из найденных и рассмотренных аналогов на данный момент ни один не может решить комплексно указанные выше проблемы. Но при этом они показывают, что проблемы актуальны, раскрывают общие черты и логику того как должна выглядеть будущая система. Из обзора аналогов становится ясным, что все распределённые системы управления — есть следствие разграничения доступа. Не только в целях безопасности, а ещё и потому, что многим сотрудникам для более эффективной работы не нужно знать каких-то вещей вне их компетенции. Это достаточно весомый факт, который нужно будет учитывать при проектировании системы. 17 3 Объект исследования Начнём рассуждения с вопроса «Что хочет руководитель?». Руководителю бизнеса нужно знать сколько денег он заработал в результате деятельности своей компании за конкретный период времени. Бухгалтерия отлично справляется с этой задачей. Она знает цифру своего счёта в начале периода и цифру в конце этого периода. Но действительно компетентному руководителю помимо этой цифры важно знать, почему так получается. Почему в результате одной деятельности у него одна прибыль, а в результате другой — другая прибыль [2]. Учитывая, что деятельность компании состоит из множествамножества действий, их нужно уметь классифицировать по каким-либо критериям и затем анализировать. Это и должна обеспечивать система управления. Для обозначения определённых участков деятельности компании используется термин «проект» который объединяет некоторые однозначно связанные действия в единую транзакцию. Под проектом будем понимать запланированную деятельность, направленную на разовое взаимодействие с клиентом. В случае когда клиентом является компания использующая систему проект называется внутренним. Когда клиентом является внешняя компания — проект называется внешним и представляет собой сделку. Проект нужен для оценки деятельности компании, а именно эффективности работы. Исходим из задачи системы — определять рентабельность проектов и следить за ходом работ. Вся деятельность компании разбита на проекты. При этом для каждого проекта характерны те или события, которые регулярно в процессе возникают. Чтобы отследить ход проекта необходимо составить список запланированных событий и смотреть как они выполняются. У каждого события есть факты, которые представляют собой некоторую неделимую единицу работы. События и соответственно факты бывают финансовые, документальные и товарные. Финансовые факты как раз влияют на оценку рентабельности проекта (сколько в итоге денег было потрачено и сколько получено). Документальные факты нужны для отчётности, а товарные — для учёта на складе. Самая важная задача руководителя и заключается в анализе этих проектов. Информации по проекту должно быть достаточно, чтобы уметь отвечать на вопрос о том, почему один проект был более эффективным, чем другой. Под эффективностью понимается количество денег, которые он принёс. А на эффективность влияет много факторов: менеджер проекта, клиент, процесс 18 работы над проектом, документы, товары на складе и т. д. Получается, что в системе в любом случае хранится информация и по финансам и по кадрам и по товарам и по документам. Вообще говоря это даже удобно, т. к. в систему можно так же заложить функции по контролю каждой из этих составляющих. Получается, что в системе хранится какая-то деятельность, а затем мы можем поглядеть на неё с разных точек зрения. Если быть точнее — с точек зрения людей ответственных за какой-либо аспект этой самой деятельности. Рис. 1. Взгляд на деятельность компании с точки зрения аспектов Абстрагируясь от системы, руководителю малого предприятия нужен инструмент исследования деятельности с точки зрения различных аспектов и различных ценностей [3]. Это можно показать на примере ведения проекта. Когда сотрудника интересует сумма денег по проекту, то ему нужно фиксировать только приходы и уходы. В данном случае информация о приходе и уходе товара — избыточна. Так же как и информация о том, кто ведёт проект тоже не нужна. С другой стороны, в конце месяца каждый сотрудник сообщает своему руководителю, что он работал и работал хорошо. Тогда нужно уметь смотреть все проекты этого сотрудника и то как они шли. В случае, когда руководителю нужно знать сколько товара компания приняла и отдала по проекту — его не интересует кто занимался проектами и какая по ним была сумма, а интересует только то, как передвигался товар и думать нужно категориями поставки. Другая задача — какой товар был самый популярный за последние 3 месяца. 19 С точки зрения каждой задачи, часть информации о деятельности компании является избыточной. Но это вовсе не означает, что она не нужна! На самом деле система нужна для по большей части для руководителей и для анализа деятельности компании. Однако не стоит забывать об исполнителях, ведь именно они заполняют систему и именно они должны делать это быстро и удобно. Каждый руководитель считает, что важна только его часть работы, а всё остальное не имеет значение. Тем сложнее проектировать систему, ведь система состоит именно из требований руководителей [1,3]. Так что на самом деле задача проектирования системы — создание удобного сервиса внесения информации для исполнителей и функций анализа для руководителей. Создать просто какую-то систему управления нет труда. Вся сложность заключается в создании удобной системы управления с понятными и удобными интерфейсами для различных групп пользователей. Таким образом, система представляет одни и те же данные в разных формах для разных групп пользователей. Это очень похоже на предыдущую работу — иерархический планировщик задача. Но здесь задача будет сложнее и более общей, т. к. изначально сущности никак не упорядочены. Но суть та же. Есть информация о деятельности компании. Задача — создать сервис, который позволит смотреть на неё с различных аспектов. Стоит отметить, что проект сам по себе является иерархической структурой, а отдельные сервисы — это проекция части проекта. Так же стоит отметить, что проект сам по себе является взглядом с одной стороны на деятельность компании, то есть фактически мы разбили деятельность компании по клиентам. Для удобства будем считать что на каждый проект выделен один ответственный менеджер, который единолично этим проектом занимается, хотя участников в проекте может быть несколько, каждый из которых отвечает за свой участок работ. В данной работе будем считать, что система планирования ресурсов - это управление структурно упорядоченной информации о планировании ресурсов предприятия разбитой функционально по модулям для произведения операций с планами ресурсов с точки зрения различных задач. 20 4 Предыдущая работа Для того, чтобы построить новую эффективную систему необходимо воспользоваться предыдущим опытом, поэтому далее будет приведён анализ достоинств и недостатков предыдущей системы GLOSYS. Этот анализ повлияет на определение объекта исследования. Изначальная задумка архитектуры системы была такой, что все модули по сути своей универсальны и могут легко подключаться и отключаться. Эта концепция была реализована в двух вариантах: строить систему на универсальных таблицах строить систему в древесной форме. Первый вариант реализовывал сторонний программист. Он разработал каркас, который пронизывает всю систему. Им же был принят стандарт на все таблицы в БД системы, т.е. все таблицы имели одинаковую форму. Из-за того, что таблицы все были стандартизированы, у них был стандартный набор полей. Часто нужно было хранить какой-то параметр, который есть не у всех записей, а поля для него в таблице нету. На этот случай было создано текстовое поле params, в котором через четыре запятые хранились параметры со своими значениями. Ничего плохого в таком подходе нет, когда информация в этом поле просто и есть и потом как-то выводится. Плохо, когда нужно искать по параметрам в этом поле. И при такой архитектуре так и происходит. Как итог получаются запросы вида: SELECT … FROM … WHERE params like «...» and params like «...» and … Поиск подстроки в строке гораздо медленнее, чем сравнение двух чисел. Поэтому хранение параметров по которым производится поиск или сортировка — является плохой идеей. В некоторых случаях были проведены работы по оптимизации, и параметры хранились в неиспользуемых полях универсальных таблиц. Таким образом, финансовые приходы и уходы проекта хранились в поле gallery, что, очевидно, неправильно. Код так же как и таблицы универсален. Есть каталог с главными скриптами. Эти скрипты очень небольшие и занимаются включением определённых модульных скриптов по входным параметрам. С одной стороны подход имеет смысл, с другой — не всегда понятно как работает перенаправление. Функции вынесены в отдельный файл, причём даже если эти функции используются один раз. Внедрять javascript и вообще его использование в такой архитектуре представляется невозможным. Используется множество компонентов iframe, что затрудняет отладку. Иногда форма 21 заполнения и её обработчик могут содержаться в одном файле, а иногда и в разных. В итоге каркас системы получился запутанным. Древесный вариант реализовывал я, и он заключался в использовании древесных таблиц, когда используется минимальное число атрибутов, и вся информация хранится в отдельных записях, в том числе и параметры. Получилось неэффективно как по объёмам данных, так и по скорости доступа. Любую деятельность можно представить иерархически, однако не всегда удобно так информацию хранить. Единственное пока что пригодное применение деревьев — это достаточно гибкая настройка модуля планирования и событий проектов. Стоит отметить, что сконфигурировать нужную структуру и функциональность дерева проще, чем создавать для неё код отдельно. С точки зрения идеологии системы можно выделить ряд положительных свойств. Во-первых это проекты. Проекты состоят из плановых событий, т. е. каждый проект помимо своих характеристик имеет список из плановых событий. Учитывая, накопленный опыт менеджеров можно выделять типовые списки плановых событий, т. е. шаблоны. Например: «Договор», «Закупка товара», «Персонализация товара», «Получение денег по договору», «Списание товара», «Закрытие проекта». В каждом плановом событии есть факты. Причём что это за факт зависит от типа события, которых было выделено четыре: финансовые, документальные, товарные и просто события. Для финансового события фактами являются приходы или уходы денег из компании, для документального — список документов, для товарного — список товаров. Всё это нужно для контроля. Плановые события представляют собой некий план ведения проекта и сразу видно, на каком этапе появились проблемы. И руководитель может принять меры к тем, кто ответственен за проблемный пункт плана. Финансы, проекты, документы и товары представляют собой отдельные модули системы. В старой системе был большой модуль администрирования, в котором вручную назначались доступы вплоть до функций к каждому модулю для каждого пользователя. «Вплоть до функций» говорит о том, что доступы назначались даже для функций «создать проект», «редактировать проект», «удалить проект», «добавить плановое событие» и т. д. В связи с этим добавление нового сотрудника и назначение ему прав представляется проблемой. Выводы по анализу: Модульный подход нужно использовать, но каждый модуль системы должен максимально не зависеть от всех других модулей. Каждый модуль 22 замкнут внутри себя и из ядра системы использует только библиотеки общих функций — html-хелперы и общие функции типа авторизации, обработки форматов данных и т. д. Таблицы стоит проектировать с точки зрения здравого смысла, т. е. создавать отдельные атрибуты таблицы для тех полей по которым производится поиск и сортировка, а поля описательного характера хранить в текстовом виде полях аналогичных полю params. Использовать иерархичность как средство представления деятельности компании, а не хранения данных. Хорошо подходит для реализации концепции перестраиваемых деревьев. Имеет смысл рассматривать деятельность компании с различных точек зрения. Понятие проекта и разделение его по аспектам — хорошая, естественная для мышления идеология. Администрирование должно быть таким, чтобы управление правами пользователей осуществлялось быстро. 23 5 Границы исследования 5.1 Минимальная система Для того чтобы понять, что из себя представляет объект исследования, необходимо определить границы — что будет считаться минимальной системой и что будет считаться максимальной системой. Минимальной в том смысле, какой минимальный набор функций нужен, чтобы она заинтересовала целевую аудиторию. Максимальной — когда она охватывает все аспекты работы малого предприятия. Для этого была проанализирована схема бизнес-процессов (рис. А1 и рис. А2). При конструировании новой системы был определён минимум: Проекты, Финансы, Документы, Товары, Партнёры, Кадры. Именно в таком составе эта система представляет интерес для того бизнеса, о котором мы говорим. Можно сколько угодно создавать сервисы для работы с сотрудниками (отпуска, бонусы, табеля и т.д.), но ведь прибыль приносят проекты, и самым важным аспектом системы является именно анализ проектов. Как было сказано выше, проект — это совокупность нескольких аспектов — событий, которые были разделены на различные типы. И есть взгляд на эти проекты с точки зрения каждого аспекта. Оценка финансов, документов и товаров — это проекция деятельности компании. Поэтому в отличие от системы GLOSYS, не нужно выделять модули «Финансы» и «Документы», т. к. они являются частью проекта.«Финансы», «Документы», «Товары» и «События» - это будут представления модуля проекта в одном ряду с «Полным представлением». 5.1.1 Модуль «Проекты» Каждый проект содержит в себе плановые события. Плановые события имеют тип в зависимости от планируемой деятельности. Предполагается что в компании деятельность может быть одним из четырёх типов: финансовое событие — приходы и уходы денег по проекту документальное событие — все документы проекта товарное событие — все товары проекта со склада свободное событие — любая текстовая информация по проекту Когда менеджер создаёт проект, то он заполняет его «карточку» и набрасывает плановые события, каждое из которых имеет какой-то тип. При этом дальнейшую деятельность по фактам этих плановых событий он не планирует в силу работы в неопредлённой меняющейся среде. Факты как раз и 24 отражают, как ведётся работа по конкретным планам. После того как план набросан, сам менеджер или другие сотрудники могут начать вносить факты. Как правило, заказ начинается с товаров, поэтому сперва добавляются факты товарных событий. Факты товарных событий — это набор товаров со склада в нужном количестве и по нужной цене. Товарные факты вносятся тем менеджером который создал проект. Рис. 2. Проект в системе Фактами финансовых событий являются приходы и уходы денег в компанию и из компании соответственно. Эти суммы вносит в систему бухгалтер. Факты документальных событий вносят бухгалтера и менеджеры продаж. Здесь фактами являются документы на товары проекта, хранимые либо прямо в системе, либо в виде записи о том что такой документ где-то фигурировал. Факты для свободных событий представляют описание хода работ, например «Клиент обнаружил брак», «Недосдача товара» и т.д. Проекция «Сделки» В этом подразделе проектов должен быть возможен просмотр всех проектов и сводной информации по ним. А так же фильтрация и поиск по различным критериям. В этом разделе должно быть и управление шаблонами плановых событий. Только в этом разделе можно создать проект и просмотреть проект, и только в этом разделе можно вносить информацию в проект (планы и их факты). При помощи такой жёсткой иерархии можно обойти множества проблем и ошибок внесения информации в систему. 25 Проекция «Финансы» Проекция финансов — это все приходы и уходы компании одним списком с возможностями фильтрации и сортировки отображения про различным критериям. Внесение платежей их внешних документов и управление счетами компании должно быть в этом разделе. Проекция «Товары» Здесь должен быть список всех товарных фактов с возможностью фильтрации и поиска по заданным критериям. Здесь должно быть управление складами. Проекция «Документы» В этом разделе должен быть список всех документов проектов с возможностью фильтрации и поиска по заданным критериям. Здесь должно быть управление видами документов. 5.1.2 Модуль «Товары» Товары - это тот самый элемент MRP, который отсутствует в современных web-CRM, но очень нужен для таких компаний как «Кьюти-дизайн». Товары хранятся на складах, которых может быть несколько. Есть полный список товаров которые есть вообще — это так называемый каталог. Там находятся и те товары которые сейчас есть на рынке вообще, и те, которые там были, но могут появиться снова. Есть ещё список товаров, которые доступны для продажи по заданным ценам — это прайс-лист компании. При этом товар может быть доступен только для продажи под заказ Ещё есть список товаров, которые готовы к продаже непосредственно т. е. они имеются в наличии на складах компании. Особенностью модуля Товаров является то, что в отличие от других систем управления, в разрабатываемой системе есть возможность автоматического обновления каталогов поставщиков. 5.1.3 Модуль «Клиенты» В данном модуле должен быть постоянно пополняемый список клиентов компании. А так же список юридических лиц, с которыми компаний взаимодействует. Это особенность бизнеса в России. Есть база клиентов которые приходят как заказчики и заказывают продукцию. А когда это же клиенты платят, то платят как правило безналичным расчётом от юридического лица. И проблема в том, что список клиентов и список юридических лиц — 26 разные. Например, когда компания имеет много филиалов (МТС, Мегафон, Ростелеком), а юридическое лицо одно. Нужно вести учёт клиентов для привязки к проектам и учёт юрлиц для привязки к платежам. 5.1.4 Модуль «Кадры» В этом модуле должна храниться информация как о сотрудниках компании, так и о входах в систему. Информация о сотрудниках не может меняться. Когда сотрудник уходит из компании, информация о его действиях должна оставаться в системе, в то время как входы в систему — информация постоянно меняющаяся и представляющаяся в виде логин-пароль. В этом же модуле должно быть штатное расписание (распределение сотрудников по отделам) и администрирование (распределение сотрудников по входам). 27 5.2 Максимальная система Выше задачей было описание минимальной системы, которая будет интересна руководителям малого и среднего бизнеса. Список модулей такой системы был описан выше. Однако, встаёт вопрос: «А что такое максимальная система?» Деятельность компании может быть статической и динамической. Статическая — это внесение свершившихся фактов. одной стороны это решает задачу учёта и анализа деятельности для дальнейшего планирования. А с другой стороны есть потребность составлять планы динамически. В частности планировать задачи и ставить по ним работы. В максимальной системе должен быть менеджер работ/заявок. При внесении в систему информации, часть информации вносится как факты, а часть информации как «заявки» на работы. Затем специальные ответственные люди (руководители отделов) из этого списка заявок создают работы для своих подчинённых. Причём работы эти собраны в виде расписания. Далее есть два варианта: сотрудник имеющий доступ в систему заходит на свою страницу и видит план на день. В конце рабочего дня он отмечает, что было сделано и генерирует отчёт. Если сотрудник не имеет входа в систему (например, водитель), то руководитель распечатывает план на день и раздаёт своим подчинённым. Ещё одна часть планирования, который делает статическую часть системы планируемой — это система таймлайна планов. Предположим, что факты, которые вносятся пользователями могут быть внесены на будущее. В минимальной системе такой факт внесётся как свершившийся факт, что на самом деле не правильно. Такие факты должны совершаться как «планируемые» и когда время подходит к этому факту, то система спрашивает пользователя действительно ли этот факт свершился. На что пользователь может отреагировать как: «факт произошёл», «факт не произошёл и не произойдёт», «факт не произошёл, но произойдёт в будущем». Третья часть системы — это деревья, которые могут быть организованы по одному из четырёх типов: Модуль планы. В отличие от проектов они не привязаны к клиентам и не имеют дат. Как развитие части такого плана могут быть перенаправлены в проект как плановые события. Модуль валлет нужен для хранения информации в виде ключ-значение. Назначение этих записей в том, чтобы хранить в них пароли, серийные номера, 28 пинкоды и т. д. Фактически это учёт чего-либо в компании. Например, за каждой программой может числиться какой-либо серийный номер, так же как и для устройства. Могут быть аккаунты с паролями для входа в какие-либо подсистемы. Такой модуль необходим офис-менеджерам Модуль учёт — это записи, наполнение которых сменяется во времени. По сути это может быть учёт товаров/материалов на складе. Основная идея в том, что есть сущность, у которой изменяются параметры. Информация — это дерево свободной информации, нужной, например для инструкций. Предполагается два пути её реализации. Свободная информация, которая порождает поддерево только информации. Либо же информация, которая порождает любое поддерево из этих четырёх типов записей. И заключительным компонентом максимальной системы является расширение модуля «Сотрудники». В этом модуле должны быть организованы такие сервисы как «Эффективность работы», «Зарплаты», «Табель», «Отпуска», «Бонусы». Вместе с этим нужна система сообщений между пользователями. 29 6 Постановка задачи Целью написания данной работы является создание системы управления для малого бизнеса. Как было написано выше, иерархическая форма представления информации в различных аспектах деятельности является хорошей методологией, т. к. соответствует естественному человеческому мышлению. Были рассмотрены аналоги и системы и определён объект системы, а именно минимальная система управления предприятием. Поэтому задачей является исследование методов работы с иерархиями объектов. При помощи этих методов проектирование и реализация минимальной системы управления предприятием для малого бизнеса. 30 7 Формальная постановка задачи Дано множество сотрудников E, множество компонент C. Множество C разделено на два подкласса A (действия) и V (представления). Так же дано множество модулей M, при этом на M определено два отношения: 1) Отношение порядка m1 > m2 если N(m1)>N(m2) 2) Отношение иерархии m1 >> m2 если m2 потомок m1 Где N(m) - функция номера от модуля. Известно, что есть функция Q, которая сопоставляет каждому элементу из M некоторое подмножество С. Эта функция указывает из каких компонент состоит модуль. Дано множество триплетов T состоящее из элементов<e, m, c>. Это множество определяет доступ сотрудника e из E в компонент c из C модуля m из M (один компонент может входить в несколько модулей). Тогда можно определить функцию P, которая отображает E, M, C в T. Эта функция - назначение сотрудникам доступ в модули. Так же задано множество данных D, которое представляет собой множество проектов, финансовых фактов, товаров и т.д. Тогда может быть определена функция F, которая отображает элементы множества D в множество C, т.е. определяет с какими данными работает каждый компонент. Задачу данной работы можно разбить на два этапа: 1) Найти и реализовать функцию F. 2) Реализовать пользовательскую настройку функций P и Q. 31 8 Проектирование 8.1 Общий подход к проектированию системы Ранее упоминалось, что существуют системы, которые решают вышеописанные задачи. Это системы класса CRM, ERP. Часть этих систем не имеет нужного функционала. Системы, рассчитанные на малый бизнес слишком просты и узкоспециализированы. Другие системы подходят для крупных корпораций, т.к. у них своя логика управления компанией, которой не подчиняется малый бизнес. Другой аспект - в средних и крупных фирмах люди считаются безликим ресурсом и всю работу выполняют отделы, которые должны содержать определённое количество человек с определёнными характеристиками. В таких системах не учитываются или слабо учитываются индивидуальности. К каждому отделу строго назначена какая-то функциональность, и управление персоналом сводится к тому, чтобы места этого отдела заполнились людьми. Когда одно из мест освобождается, на это место снова приходит некий безликий человек. В малом бизнесе всё совсем не так. Изучая двадцатилетнюю историю нескольких небольших сувенирнодизайнерских компаний стало ясно, что малый бизнес должен постоянно меняться, чтобы выжить. Как минимум раз в год производятся структурные изменения. Это значит, что все системы, которые направлены на управление крупными корпорациями, уже не работают эффективно для малых предприятий. Система, отвечающая нуждам постоянно меняющейся компании должна сама постоянно меняться и быть гибкой. На пути к новому подходу было опробовано множество разных решений. Например использование нескольких различных узкоспециализированных сервисов. Несмотря на то, что такие системы построить несложно, их архитектура не позволяет единым образом обрабатывать информацию и создавать универсальные отчёты. Другой подход - масштабировать уже имеющуюся систему, или архитектуру до размеров малого бизнеса. Тогда появляются проблемы, описанные выше, которые связаны с гибкой природой малых предприятий. Часто системы для малого бизнеса создают с нуля. Если бизнес реорганизуется каждый год, то каждый год нужно создавать новую систему или тратить время на переработку старой. Приняв во внимание все эти сведения, в данной работе предложен метод построение простой, гибкой и перенастраиваемой системы. Новый подход использует идеологию компонент. В системе нет жёстко обозначенных модулей 32 системы, как это часто делается в крупных ERP системах. Предлагается всю систему строить из отдельных небольших компонент. Каждый компонент представляет собой какую-то конкретную функциональность, он не зависит от других компонентов системы и является самодостаточен, хотя работает с общими данными, которые могут использовать в своей работе другие компоненты. Модуль лишь объединяет в себе компоненты позволяя компоновать систему в соответствии с нуждами компании и взглядом руководителей на реальную жизнь. Каждый модуль, как правило, обеспечивает функциональность какого-то отдела или подразделения. В каждый модуль и каждому компоненту модуля даётся возможность настроить доступы конкретным сотрудникам. Таким образом, возможно быстрое переназначение как людей из одних отделов в другие, так и смена функциональности отдельного модуля. При этом внутреннее представление системы остаётся прежним. Вся архитектура системы может меняться в течение нескольких часов, не теряя своей работоспособности. 8.2 Компоненты В разрабатываемой системе модули спроектированы определённым образом. Зачастую, проектируя сложные системы, разработчики, не имея контакта с клиентом (или будущими пользователями), следуют логике разработки системы с точки зрения программирования или какой-то системы классификации функций. При этом разработчики часто совсем не задумываются о том, как система будет выглядеть для пользователя. Часто оказывается так, что пользователям неудобны или непонятны те решения, которые предлагает программист. Как показывает практика - учить людей работать в своей системе - непросто. Хороший подход - когда пользователь чувствует, что система помогает ему справляться со своими задачами. Что работа в системе соответствует стандартной логике работы человека. Исходя из этого можно сказать, что систему следует проектировать следуя задачам различных пользователей. Соответственно проектировать компоненты таким образом, чтобы они соответствовали задачам пользователей, а не “общей концепции“. В данной работе ведётся проектирование и разработка именно такой системы. Поэтому, основываясь на опыте работы со старой системой различных групп пользователей, был составлен список необходимых компонент для минимальной системы: 33 Управление проектами Аналитика по проектам Управлением шаблонами структуры проектов Управление структурой проекта Управление статусами проектов Финансовые потоки Управление банками/кассами Финансовые переводы Импорт Финансов из внешнего файла Управление документами Управление планами Управление кадрами Управление доступами Штатное расписание Управление статусами сотрудников Управление списком партнёров/клиентов Аналитика партнёров/клиентов Управление списком юридических лиц Управление профилями партнёров Каталог товаров Импорт товаров из внешнего файла Управление поставщиками Управление видами нанесения Управление характеристиками товаров Управление категориями товаров Управление складами Управление видами складов Управление сроками хранения товара Управление потоком товаров Транспортный график Разбор заявок Часть этих компонентов является настройками системы. Одним из удобств организации модулей из таких компонент является то, что можно как создать отдельный модуль-конфигуратор, так и поместить конфигураторы в соответствующие модули. 34 8.3 Формальное определение компонент В формальной постановке задачи было определено множество D, которое является данными для работы системы. Определим, из каких подмножеств состоит это множество: Множество компонент C Множество модулей M Множество сотрудников E Множество триплетов T Множество проектов Pr Множество шаблонов структуры проектов Pat Множество видов плановых событий Evnt Множество статусов проектов Pstat Множество должностей Stf Множество статусов сотрудников Sstat Множество финансовых транзакций Fin Множество банков Bnk Множество документов Doc Множество планов Pln Множество Клиентов Cli Множество Юридических лиц Jur Множество профилей клиентов Prof Множество позиций каталогов Cat Множество категорий товаров Class Множество характеристик товаров Prop Множество складов Store Множество типов складов Stype Множество заявок Brf Теперь можно формально определить некоторые компоненты, тем самым определив функцию F, которая отображает данные D в множество компонент C: Управление проектами - Pr, Doc, Fin, Pln Аналитика по проектам – Pr, Fin Управлением шаблонами структуры проектов – Pat, Evnt Управление структурой проекта - Evnt Управление статусами проектов - Pstat Финансовые потоки - Fin 35 Управление банками/кассами - Bnk Финансовые переводы - Fin Управление документами - Doc Управление планами - Pln Управление кадрами - E Управление доступами – C, M, E, T Штатное расписание - Stf Управление статусами сотрудников - Sstat Управление списком партнёров/клиентов – Cli, Prof Аналитика партнёров/клиентов – Cli, Prof, Jur Управление списком юридических лиц - Jur Управление профилями партнёров - Prof Каталог товаров – Cat, Class, Prop Управление характеристиками товаров - Prop Управление категориями товаров - Class Управление складами - Store Управление видами складов - Stype Управление потоком товаров – Stype, Store, Cat Транспортный график - Brf Разбор заявок - Brf 36 8.4 Подсистемы При разработке сложных систем следует выделять основные подсистемы, которые должны быть как можно более независимыми. Ниже представлен список основных подсистем: 1. Подсистема обработки серверных запросов – набор более высокоуровневых функций для работы с базами данных. 2. Подсистема сборки отображения для клиента – поиск нужных компонент, проверка доступов, построение зависимостей, вывод в клиентскую часть. 3. Подсистема обработки форм – обработка пользовательской информации, бизнес-логика форм 4. Подсистема вывода форм – отображение, порядок вывода форм, набор функций для вывода форм в различных ситуациях(отдельными окнами, вкладкой, элементом страницы) 5. Подсистема генерации полей – генерация всех обработчиков поля в зависимости от типа (текстовые поля, числовые поля, поля даты, поляинтервалы, поля пред-заполнения и т.д.) 6. Подсистема управления вкладками – закрытие и открытие вкладок, вывод в них требуемого содержимого. 7. Подсистема управления фильтрами – генерация фильтров по заданному шаблону, запрос к подсистеме обработки запросов с заданными параметрами. 8. Подсистема управления подсказками – создание и просмотр подсказок на любой элемент интерфейса. 8.5 Архитектура Несмотря на то, что предлагается универсальный подход, система будет строиться исходя из описания минимальной системы в понимании сувенирного бизнеса. Поэтому, следуя опыту компании, выделяются основные модули: Деятельность Кадры Клиенты Товары Настройки Конфигуратор системы 37 В модуле «Деятельность» должно существовать пять подразделов, которые являются проекцией деятельности компании: Проекты Поток финансов Поток документов Поток товаров Список планов Для разработки модулей предлагается использовать шаблон проектирования MVC. Тогда каждый модуль разбивается на две части клиентскую и серверную. Клиентская - это интерфейс пользователя, формы. Серверная - обработчики этих форм. Сложность системы определяется не столько блоками системы, сколько связями между этими блоками. В качестве блоков интерфейса будем считать формы, с которыми работает пользователь. В качестве связей будем считать вызов одной формы из другой [2]. 8.6 Модуль «Деятельность» В модуле Деятельность, который представляет собой проекты, необходимо использовать иерархический подход. Сущностью верхнего уровня является Проект, у которого есть свои характеристики, такие как менеджер проекта, клиент, дата создания, статус и т. д. Сущностью второго уровня является плановое событие, которое однозначно соотносится с проектом. Плановое событие может иметь один из четырёх основных типов: Финансы, Документы, Товары и Услуги, Ход работ. Для некоторых типов событий определены подтипы: Финансы — приходы и уходы, Документы — вид документа, Товары — виды товаров,. Сущностью третьего уровня является факт события. Факты так же имеют свой тип в зависимости от того, к какому событию они относятся. В зависимости от типа, события и их факты должны по-разному анализироваться при оценке деятельности компании. Сущностью четвёртого уровня должно быть дерево комментариев. В любой компании есть проекты различных видов. И система должна уметь со всеми ими работать. Примерно 80% проектов нашей компании - это продажа сувениров под заказ, из них часть с нанесением, которое выполняет наша компания или подрядчики. Однако 20% проектов приходится на собственное производство, с чем в данный момент возникают проблемы. 38 Здесь возникает задача разделения рентабельность проектов и финансовых потоков компании. В товарах и услугах нужна возможность ставить «плюсы» и «минусы». Плюсы - это та сумма за которую менеджер продаёт товар. Минусы - стоимость товара, услуг, работ. В отличие от финансов в этом разделе содержимое имеет потребность к частым изменениям. Все дополнительные работы и расходы добавляются во время жизни проекта. В конце получается рентабельность. Бизнес устроен так, что у компаний есть кредит доверия относительно друг-друга. И главная проблема заключается в том, что логика жизни такова, что почти никогда не удаётся сопоставить финансы и затраты по проекту, т.к. деньги обычно приходят и уходят в проект уже после того как все работы были выполнены а менеджеру выплатили премии. В этом плане теория очень сильно расходится с практикой и система должна уметь работать и в таких ситуациях. Поэтому в товарах и услугах записываются все расходы и приходы, даже если они фактически ещё не были совершены и не прошли через бухгалтерию. И это позволяет определять рентабельность каждого проекта и при необходимости посмотреть, почему она получилась именно такая какая получилась. Составляющими модуля проектов могут следующие компоненты: Управление проектами – список проектов со сводной информацией по ним. Возможность добавлять новые проекты, просматривать и редактировать существующие. Так же сюда входят формы для добавления плановых событий проекта. Аналитика по проектам – список проектов с подробной информацией и расширенными режимами фильтрации. Формы построения графиков. Управлением шаблонами структуры проектов – форма редактирования шаблонов (поддеревьев планов) Управление структурой проекта – форма для редактирования шаблонов дерева (подобно настройке дерева типами узлов, в предыдущей работе) Управление статусами проектов – редактирование списка статусов Управление отчётным списком товаров – отдельная форма управления списком и выписки документов. 39 Рис. 2. Отчётный список товаров в проекте Этот список может базироваться на списке товаров, а может и не базироваться. Но идея в том, что по этому отдельному отчётному списку выписываются счета, фактуры и товарные накладные. Этот список был бы не нужен, если бы у нас был список товаров и только на них выписывались бы документы. Но как показывает практика, для отчётности бывает необходимо оформить документы на произвольный список товаров. Бывают так же случаи, когда каких-то товаров или услуг нет на складе или в каталоге. А самая частая проблема — выписка документов на часть товара, привязанного к проекту. 8.7 Модуль «Кадры» Функция этого модуля – управление кадрами компании. Это может быть назначение должностей, управление доступами, в дальнейшем рассчёт зарплаты, оценка эффективности, табель и т.д. Но в данной работе данный модуль может состоять из следующих компонент: Управление кадрами – список сотрудников и сводной информации по ним, добавление сотрудников в систему. Управление доступами – распределение доступов как пользователей по модулям, так и модулей по пользователям. Штатное расписание – редактор иерархии должностей в компании Управление статусами сотрудников - редактирование списка статусов 40 8.8 Модуль «Клиенты» Модуль клиентов представляет собой клиентскую базу с возможностями аналитики. Например, вывод распределения клиентов по отраслям деятельности. Отрасль деятельности – важный параметр партнёра, так же как параметр определяющий является ли партнёр клиентом и/или подрядчиком Компонентами данного модуля могут быть: Управление списком партнёров/клиентов – список клиентов и сводная информация по ним, возможность добавить клиента в базу, просмотреть или редактировать карточку клиента. Аналитика партнёров/клиентов – список клиентов с расширенной фильтрацией. Управление списком юридических лиц – список юридических лиц и сводная информация по ним, возможность добавить юридическое лицо в базу, просмотреть или редактировать карточку юридического лица. Управление профилями партнёров – редактирование списков отраслей для клиентов и подрядчиков. 8.9 Модуль «Настройки» В этом модуле одна форма для редактирования персональных настроек пользователя. При помощи конфигуратора в этот модуль можно включить компоненты для настройки системы, например: Управлением шаблонами структуры проектов Управление структурой проекта Управление статусами проектов Управление доступами Штатное расписание Управление профилями партнёров Управление поставщиками Управление видами нанесения Управление характеристиками товаров Управление категориями товаров Управление видами складов В данном модуле в будущем может быть так же добавлена и подсистема заданий/заявок. 41 8.10 Модуль «Товары» Модуль товаров пока ещё не спроектирован. Есть два типа товарного события: это закупка товара на склад и списание товара со склада. При закупке товара на склад возникает ситуация, когда товар был закуплен, но он едет. То есть у товара есть некоторое промежуточное состояние, что он «в пути». Когда он доезжает, то ответственный сотрудник заносит его на склад. А при списании товара со склада возникает ещё больше непонятных вещей. Например, менеджер договорился с клиентом, но деньги за товар будут только через несколько дней. Нужно чтобы это товар был «помечен» в резерв. Чтобы не было таких ситуаций, когда два менеджера продали двум разным клиентам 10 ручек, хотя их есть всего 10. С другой стороны клиенты — это такие люди которые за эти несколько дней могут передумать, т. е. товар как должен иметь возможность стать «помеченным» , но ненадолго, так и возможность снять с него метку. Принимая во внимание поток проектов и кратковременную память человека, убирание товара из резервов должно быть автоматическим. В общем, все эти проблемы учёта связаны с тем, что даже на небольшом предприятии из-за потока проектов и коммуникаций с клиентами, между событиями проходит некоторое время. 8.11 Модуль «Конфигуратор системы» Данный модуль построен в иерархической структре, т. к. это наиболее полно соответствует описаниям настроек. Конфигуратор системы включает в себя следующие иерархические разделы: Конфигуратор модулей Конфигуратор компонент Управление доступами Управление системой подсказок Система подсказок — особый раздел в конфигураторе, в котором можно редактировать некоторые надписи в системе. Этот раздел в конфигураторе должен быть структурирован. Предлагается группировать надписи по формам. На самом деле это всего лишь настройка под конкретный тип бизнеса. Не будет никакой автоматический генерации форм по той причине, что это противоречит «принципу удобного интерфейса». Именно поэтому все хэлпники будут хранится в конфигураторе, но использоваться и вставляться в формы разработчиками. 42 Конфигуратор модулей представляет собой иерархическую структуру. Модули могут входить друг в друга образуя различные иерархии. У каждого модуля есть список его частей, который всегда одинаковый: доступы, действия, представления. Последние две части – это список компонент, которые отображаются в модуле в правой или левой частях главного представления. Если доступы не указаны, то по умолчанию все пользователи могут работать с этим модулем. Компоненты модуля – это отдельный список со своими параметрами. Этот список общий для всех систем, поэтому конфигурируется только в глобальном модуле администрирования. Управление доступами подразумевает создание входов в систему и назначение их пользователям. Интересный вопрос: делать ли связь логинов и сотрудников однозначной? Можно представить себе ситуацию, когда стороннему человеку(клиенту например) даётся доступ к какой-либо части системы. Так же можно представить, что в компании есть сотрудники без доступа в систему. Как говорилось ранее, необходимо сделать две иерархии. Первая — это система объединения входов в группы для удобного назначения прав пользователям. Вторая — это штатное расписание, чтобы знать у кого какие должности. А вот вопрос корреляции групп доступа и штатного расписания — это хороший вопрос для исследования. Стоит так же отметить, что входы в систему — это только входы, в проектах и фактах хранится информация только о пользователях, а не входах. 43 9 Реализация 9.1 Система Система реализуется в виде web-приложения на языке php с использованием javascript. Было решено не использовать PHP фрэймворки, т. к. они обладают низким быстродействием. Зато было решено использовать библиотеку jquery и уже разработанный конфигуратор системы. Построение новой системы разумно строить на информации старой системы, т. е. проектировать базы данных ориентируясь на ту информацию, которой хранится в ГЛОСИС. В файловой системе нужно было сделать некоторые перегруппировки файлов таким образом, чтобы модули представляли собой максимально независимые части системы. Первыми были созданы подсистемы. Одной из самых важных оказалась подсистема сборки клиентского интерфейса. Задача этой подсистемы по сконфигурированным модулям определить какие компоненты будут задействованы, подгрузить необходимые библиотеки и сгенерировать функции переходов. Здесь же задействуется подсистема вкладок для вывода информации пользователю. Следующая подсистема – это система фильтров, которая генерирует фильтры по информации на странице. Для внесения информации в базу данных было решено разработать универсальную систему компоновки форм. В старой системе ГЛОСИС и вообще во многих приложениях формы выглядят как описание полей и сами поля. Тогда зная список полей и его описания можно автоматически создавать некоторые примитивный формы, такие как внесение платежей, заведение сотрудников, заведение клиентов и т. д. За серверную часть отвечает подсистема обработки запросов, а за клиентскую – подсистема генерации форм. Был разработан и реализован модуль полуавтоматического внесения возможных товаров поставщиков на склад, т. е. поддержание актуального прайс-листа с минимальным привлечением сотрудников. Но этот модуль пока что совместим только со старой системой. Для новой системы спроектирован но пока не реализован новый модуль для ещё более автоматического внесения товаров в каталог товаров. 44 Реализация компонент большей своей частью является вёрсткой интерфейса и вызовом подсистем. Составные части компоненты: 1. Конфигурация a. Список скриптов из общей библиотеки b. Список стилей из общей библиотеки 2. Вёрстка 3. Специфичные для компоненты Функции 4. Специфичные для компоненты Обработчики событий Таким образом, дальнейшая реализация системы сводится к реализации компонент и доработке подсистем. На данный момент полностью или частично реализованы компоненты: Управление кадрами Управление доступами Управление партнёрами Управление юридическими лицами Управление профилями партнёров Список финансов Перевод финансов между кассами Управление банками Список хода работ Список проектов (не до конца) Каталог товаров (не до конца) 45 9.2 Интерфейс Интерфейс системы должен быть удобным для внесения информации сотрудниками и анализа информации руководителями. Как показала практика работы в компании «Кьюти-дизайн» — чем проще и однообразнее интерфейс — тем лучше. Поэтому интерфейсы модулей должны быть схожи в плане композиции, и различаться быть может только цветовым сочетанием (например, Проекты — зелёный, Финансы — синий, Товары — красный и т. д.). Разные модули специально покрашены в разные цвета, т.к. это важно. Да, многие солидные фирмы делают системы целиком в классической нейтральной гамме с возможностью настройки оформления. Но, если обратиться к психологии, то человек лучше различает компоненты системы когда они покрашены в разные цвета. Это может звучать нелепо, но такие вещи улучшают коммуникации между сотрудниками. Например, при общении двух сотрудников, один спрашивает: “Где это делать?”, - на что другой отвечает: “В красном модуле, нажать на плюсик”. И второй сотрудник поймёт эту фразу гораздо лучше чем: “В модуле проекты нажми на кнопку создать”. Зрительные ассоциации у человека развиты гораздо лучше, чем словесные. Хотя бы потому что зрительное восприятие врождённое, а языковое - приобретённое. Именно поэтому при разработке нашей системы мы считаем правильным красить разные компоненты системы в различные цвета, даже несмотря на то, что это может быть ассоциировано с ребячеством. В любом случае, можно будет разработать отдельное оформление для особо привередливых клиентов. Так же при разработке интерфейса было решено придерживаться двух правил: Всё должно быть по максимуму однообразным в плане композиции элементов.. От простого к простому. Все формы должны быть простыми. Если нужно что-то сверх этого, то оно открывается либо во вкладке, либо в диалоговом окне. Для быстрого перехода между модулями и разделами, сверху окна в одну строку должно быть расположено меню навигации по модулям. Если у модуля есть подразделы, то выбор подраздела осуществляется через дополнительный селектор в этом модуле путём одного клика мышью. Интерфейс строится подобно дереву, начиная с самых общих частей и заканчивая самыми конкретными. Поэтому верхняя строка полностью выделена для навигации по модулям и их подразделам. Перемещение между модулями 46 осуществляется в один клик, в то время как перемещение между подразделами различных модулей в 1-2 клика. Cправа от панели навигации, между модулями, располагается место для логотипа компании и значок выхода из системы. Всю нижнюю часть окна занимает интерфейс вкладок. В каждом модуле изначально открыта одна вкладка. Вверху вкладки, как правило, располагается заголовок вкладки в котором два селектора по краям. В левом селекторе можно менять представление вкладки (если предусмотрено в конфигураторе), в правом селекторе можно выполнять действия, такие как добавить элемент или управление параметрами (часть предусмотрена в конфигураторе). В случае действий возможно открытие новых вкладок. Начальная вкладка является компонентом представления по умолчанию, что задаётся в конфигураторе. В виду того что система строится по иерархической концепции, начальный интерфейс каждого модуля представлен в виде списка сущностей верхнего уровня. В системе ГЛОСИС каждая новая сущность открывалось в новом окне. При разработке интерфейсов новой системы было решено, что время оконных интерфейсов минуло, и все пользователи давно привыкли к вкладкам. Именно поэтому было решено открывать сущности не в новых окнах, а в новых вкладках. То есть в каждом модуле основной блок ниже полосы меню — это модуль вкладок. Изначально открыта вкладка со списком сущностей верхнего уровня. Все остальные сущности открываются либо в новых вкладках, либо диалоговыми окнами. Теперь все сущности управляются вкладками — это просмотр списка проектов, просмотр проекта, создание проекта, управление шаблонами плановых событий. Но позже стало понятно, что не стоит бездумно всё открывать во вкладках. У нас есть вкладки и есть всплывающие модальные и немодальные окна. Предлагается построить интерфейс таким образом, чтобы во кладках открывалось то с чем пользователь может работать параллельно, а всплывающими модальными окнами — то, с чем пользователь параллельно работать не может или то, с чем мы пользователю не стоит работать параллельно. То есть пользователь может одновременно смотреть список проектов или каждый проект по отдельности, создавать проект и редактировать. Но не может параллельно вносить несколько платежей в один проект или создавать несколько товарных событий. Ещё одно требование к интерфейсу - это его простота. Для каждого пользователя нужно сделать так чтобы он соответствовал только функциям, к которым он привык. Часто ERP системы проектируются так, что вываливают на пользователя даже те возможности, которые ему не нужны. В результате чего пользователь теряется. 47 48 Заключение За прошедший период времени был произведён широкий обзор предметной области: Исследование проблем малого бизнеса Исследование видов систем управления и их назначение Анализ аналогов системы Анализ старой системы GLOSYS В результате анализа были выявлены некоторые методы, которые следует применить при разработке новой системы. Были определены границы исследования, а именно сформулированы критерии минимальной и максимальной систем управления для малого бизнеса. В ходе работы был обозначен объект исследования и совершены формальная и неформальная постановки задачи. Так же стало понятно место иерархии в исследовании, и направление изучения методов работы с иерархиями. Начаты этапы проектирования и реализации системы. В процессе проектирования был найден компонентный подход, который в корне поменял направление исследования. Исследование стало носить экспериментальный характер. Так же были выделены преимущества компонентного подхода: Гибкость системы в отношении назначения должностей и функций Независимость должностей от внутренней структуры информационной системы. Каждая компания выбирает тот набор компонент, который ей необходим В процессе проектирования были выделены основные компоненты и определены основные подсистемы. Реализация находится на уровне разработки компонент. Основные подсистемы реализованы. 49 Список использованных источников 1. Абдикеев Н., Реинжиниринг бизнес-процессов. Полный курс MBA / М.: ЭКСМО, 2005, - 592 с. 2. Питеркин С.В., Точно вовремя для России. Практика применения ERPсистем / М.: Альпина Бизнес Букс, 2005, - 368 с. 3. Майкл Робсон., Практическое руководство по реинжинирингу бизнеспроцессов / Юнити, 2003, - 222 с. 4. Крылович А. В., Информационные технологии в Управлении предприятием / / [Электронный ресурс] — 2012. Режим доступа к ресурсу http://www.cfin.ru/itm/kis/tops.shtml свободный. 5. Мелехина П.Ю. Современные аспекты развития финансового механизма предприятий малого бизнеса // Российское предпринимательство. — 2010. — № 8 Вып. 1 (164). — c. 99-102. — http://www.creativeconomy.ru/articles/10776/ 6. Тимошенко Н.А., Меняев М.Ф. Информационная система учета для малого предприятия // Российское предпринимательство. — 2003. — № 2 (38). — c. 79-84. — http://www.creativeconomy.ru/articles/8641/ 7. Описание сервиса «Мегаплан» / [Электронный ресурс] — 2012. Режим доступа к ресурсу http://www.megaplan.ru свободный. 8. Описание продукта Cognos Express / [Электронный ресурс] — 2012. Режим доступа к ресусру http://www-01.ibm.com/software/ru/data/cognos/ свободный. 9. Спецификация продукта БЭСТ / [Электронный ресурс] – 2003 Режим доступа к ресурсу http://www.bestnet.ru/programs/best-4plus/#2 свободный. 10.Репин В. В., Бизнес-процессы. Моделирование, внедрение, управление / М.: Манн, Иванов и Фербер, 2013, - 512 с. 50 Список запланированных публикаций Елисафенко Михаила Евгеньевича № 1 2 3 Наименование работы, её вид Компонентная архитектура систем управления малым бизнесом (статья) Обзор архитектур систем управления для малых предприятий (статья) Компонентная архитектура систем управления малым бизнесом (тезисы) Форма работы печ. печ. печ. Выходные данные Вестник НГУ Вестник НГУ Докл. МНСК 2014 51 Объём Соавторы в стр. или п.л. Приложение (обязательное) Рис. А.1 схема бизнес-процессов 52 Рис. А.2(схема бизнес-процессов, продолжение 53
