вторник, 18 октября 2011 г.

Управление временем в трекере

1. Постановка проблемы

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

2. Что есть исполнение планового срока?

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

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

В задаче заводим реквизит факт наступления срока типа "дата", туда записываем эту дату. Кроме того, пишем служебный коммент, в котором отмечаем это событие.

Назначение события как факта исполнения делаем не для задачи, а для диаграммы. Т.е. мы не можем установить, что задача 1 считается исполненной при попадании в состояние 7, а задача 2 - при попадании в состояние 5; нет, правило устанавливается на уровне диаграммы: задача считается исполненной при попадании в любое из состояний 5, 6, 8. Реализовать это можно установкой флажка в состоянии.

3. Виды сроков

Срок типа "конкретная дата" не очень удобен - для отдаленных планов это слишком большая конкретика, удобнее планировать "в ноябре", "в 3 квартале" и т.п. Фактически задаче мы назначаем интервал времени. Поскольку задачи понимаются как нечто достаточно элементарное, то для крупных временных интервалов можно считать, что задача должна начаться и завершиться в этом периоде (требуется еще продумать этот момент).
Мы рассматриваем следующие календарные сроки:
  • Дата
  • Неделя (№ недели в году + год)
  • Месяц (+ год)
  • 1-4 неделя месяца (экзотика, но у нас используется в планировании производства)
  • 1-3 декада месяца (у нас не используется и пока не делаем)

Кроме календарных сроков, т.е. имеющих жесткие привязки к календарю (дату начала и дату конца), удобно планировать по условным этапам или итерациям. Эти периоды не обязательно имеют даты начала/конца, но мы считаем, что они имеют определенную длительность - к примеру, по две недели. Тогда мы можем спланировать проект и оценить его трудоемкость и сроки в условных периодах, не зная еще даты запуска проекта (начальной даты первого периода). Этап/итерация это специальный объект со следующими свойствами:
  • этапы рассматриваются сразу рядами: А1, А2 ... Аn. Относительно этапов в ряду считаем, что они идут один за другим и не пересекаются. Нам потребуется несколько рядов этапов для того, чтобы иметь возможность планировать независимые проекты.
  • каждый этап имеет дату начала и дату конца (привязка к календарю), но они могут быть и на начальном этапе планирования будут пустыми. То есть мы создаем ряд этапов, раскидываем задачи проекта по этапам и потом устанавливаем конкретные даты этапам, причем не обязательно всем - можно только начальным, а более поздние пока без календарной привязки.
  • для ряда этапов устанавливаем единую плановую длительность этапа - две недели, месяц - как выберем.


4. Назначение сроков задаче

Задаче могут быть назначены несколько сроков из разных рядов: к примеру, месяц Март и 12-я неделя года, этап А3 и этап В8. Из каждого ряда может быть назначен только один срок (что естественно, поскольку периоды в ряду не пересекаются). При назначении срока проверяем, не вступает ли он в конфликт с уже назначенными сроками: так при назначении срока "12-я неделя" мы должны проверить, что она пересекается со сроком "Март".
При назначении этапов А3 и В8 если у них указаны даты начала и конца, то проверяем, если не указаны - можем назначать.
По сути сроком задачи будет пересечение всех назначенных ей сроков, т.е. для задачи можно вычислить дату начала и дату конца. Эти даты не редактируются вручную, а пересчитываются при назначении срока задаче (в том числе при отцеплении задачи от ранее назначенного срока: был Март, сменили на Апрель или вообще убрали привязку к месяцу).
Дата начала не несет особого смысла - мы можем начать задачу и раньше, можем и позже. Важной является лишь дата конца и именно по ней мы будем определять, уложилось ли фактическое выполнение (см. п. 2) или нет.

5. Назначение срока этапу

Сроки этапов подчиняются следующим правилам:
  • Этапы в ряду не пересекаются и идут по возрастанию
  • При назначении дат начала и конца этапа необходимо учитывать уже назначенные сроки задач, входящих в эти этапы

Второе правило рассмотрим подробнее. При назначении дат начала и конца этапу они должны быть такими, чтобы ни у одной из входящих в этап задачи не возникло несовместимых сроков. Для этого по всем срокам всех задач этого этапа считаем C1 = max(ДатаНачалаk) и C2 = min(ДатаКонцаk). Условиями совместимости дат этапа с уже назначенными сроками будут:
    ДатаНачалаЭтапа < C2
    ДатаКонцаЭтапа > C1


6. Специальные операции с рядами этапов

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

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

7. Взаимозависимость задач

Кроме описанных выше сроков полезно уметь учитывать взаимозависимость задач. К примеру, задача 56 требует того, что описано в задаче 48. Это не значит, что для начала задачи 56 требуется, чтобы была завершена задача 48 - часто достаточно выполнения только части ее. Поэтому рассматриваем эту зависимость как "начало-конец": задача 56 не может завершиться без того, чтобы началась задача 48. на языке сроков это означает следующее: в любом ряду этапов или календарных сроков (месяцев, недель), которые назначены обеим задачам, этап задачи 48 не может быть позже этапа задачи 56. Здесь мы неявно считаем, что задачи достаточно невелики и полностью укладываются в рассматриваемые этапы. Если рассматриваемые этапы достаточно велики (хотя бы неделя), то это вполне корректное предположение.
Соответственно, необходимо сделать следующие механизмы:
  • Указание задаче списка предшествующих задач
  • Построение дерева зависимых и зависящих задач
  • Проверка корректности сроков зависимых задач относительно ряда календарных сроков или ряда этапов - т.е. проверяем, правильно ли раскиданы задачи по месяцам или по этапам

четверг, 14 июля 2011 г.

Управление правами в трекере

1 Общие положения
Управление правами осуществляется на основании ролей. В роли прописаны права на действия. Каждое право либо дано, либо нет.
Стоит сделать вектор (массив) объектов прав (то, на что устанавливаем права) и по этому образцу задавать права у ролей.
Права считаются независимыми друг от друга (т.е. при установке права не проверяется, есть или нет какие-то другие права).
Каждый пользователь может иметь несколько ролей. Права пользователя определяются объединением прав ролей, т.е. операцией .or. над векторами прав.
Каждое действие совершается, если у пользователя есть права хоть по одному основанию (особенности при движении, чтобы результат не вызвал противоречия с другими правами).

2 Инцидент (задача)
Права на инциденты устанавливаются в общих терминах, т.е. невозможно установить права на отдельный инцидент, права на него вычисляются по его свойствам (исполнитель, состояние и т.д.).
Для инцидента (за исключением права на создание) различаются права в разных есго отношениях с инцидентом:
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты
    Часть действий (критически важные) сопровождаются служебными комментариями со стандартным текстом.

    2.1 Создание инцидента
    Да/нет

    2.2 Просмотр инцидента
  • я — Исполнитель: всегда да!
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.3 Передача инцидента
  • я — Исполнитель: всегда да!
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.4 Комментирование
  • я — Исполнитель: всегда да!
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.5 Редактирование текста инцидента
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты
    Существенная особенность: редактирование текста инцидента не-Исполнителем возможно только в неактивном состоянии.

    2.6 Изменение приоритета инцидента
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.7 Редактирование тегов инцидента
    Назначение/удаление тегов у инцидента. Считаем теги, так же как и приоритет, не критичными для сохранения истории, поэтому не разделяем операции назначения и удаления тегов.
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.8 Выбор рамочной задачи
    Действие представляет собой ситуацию {номер рамочной задачи пуст} => {номер рамочной задачи непуст}.
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.9 Очистка рамочной задачи
    Действие представляет собой ситуацию {номер рамочной задачи непуст} => {номер рамочной задачи пуст}.
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.10 Изменение рамочной задачи
    Действие представляет собой ситуацию {номер рамочной задачи непуст} => {номер рамочной задачи непуст и не совпадает с начальным}.
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.11 Прицепление файла
    Действие представляет собой добавление нового файла из ЭА.
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    2.12 Отцепление файла
  • я — Исполнитель
  • я — Автор
  • я — Основной исполнитель
  • я — Владелец
  • все инциденты

    3 Состояние
    Важное отличие прав на состояние от прав на инциденты состоит в том, что права на инциденты устанавливаются как по их свойствам, так и индивидуально.

    3.1 Просмотр инцидентов в состоянии
    Просмотр инцидентов, находящихся в определенном состоянии. Если у пользователя права на состояние нет, но право на инцидент есть (к примеру, как у Владельца), то действуют более широкие права, т.е. доступ к инциденту есть.
  • все состояния
  • активные
  • ждущие
  • финальные
  • <по каждому состоянию индивидуально>

    3.2 Быть исполнителем в состоянии
    Показывает то, что данный исполнитель может быть исполнителем для инцидентов в данном состоянии.
  • активные
  • <по каждому состоянию индивидуально>

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

    4.1 Переход без доп.условий
  • все переходы
  • <по каждому переходу отдельно>

    4.2 Переход в ситуации «я — Исполнитель»
    Действие представляет собой ситуацию {задача в состоянии А, исполнитель Иванов} => {задача в состоянии Б (возможно Б=А), исполнитель Иванов}, т.е. некий переход вообще может быть недоступен, но доступен для пользователя, если он является текущим Исполнителем инцидента. При таком движении исполнитель не изменяется. Если данного пользователя нет в списке возможных исполнителей конечного состояния перехода, то такой переход не должен быть доступен вне зависимости от этого права.
  • все переходы
  • <по каждому переходу отдельно>

    4.3 Переход в ситуации «я — Владелец»
    Это возможность Владельцу дать права на движения его инцидентов.
  • все переходы
  • <по каждому переходу отдельно>

    5 Прочие права
    Прочие права должны описывать доступ к следующим объектам:
  • Реестр инцидентов
  • Отчеты (когда они будут написаны)
  • Создание/изменение текста тегов
  • ...и т.д.
    Доступ к файлам управляется на уровне прав электронного архива.
    Все это будет описано в отдельном документе.
  • вторник, 28 июня 2011 г.

    Цели и структура корпоративной wiki

    Иметь корпоративную wiki сейчас модно. Хочется разобраться, что полезного стоит за этой модой. То есть выявить возможные цели, средства и спроектировать структуру базы знаний - именно сюда относят wiki-системы.

    1. Цели, они же проблемы

    Что является проблемами при работе со знаниями? Знания и умения - это то, что в головах работников. Отсюда первый риск:
    • Риск утраты знаний при увольнении сотрудника. Для детализации необходимо определить список ключевых областей знания, возможность описания этих знаний (и форму этого описания), выявить ключевых носителей этого знания и умеют ли они писать связные тексты.

    Это наиболее обсуждаемый в литературе риск, но не уверен, что он является наиболее опасным - есть такая вещь, как корпоративная культура, и она же является механизмом передачи знаний (хотя далеко не всегда эффективным).
    Собственно, рассмотренный риск является едва ли не единственным собственно риском - когда убытки связаны с неким малопредсказуемым событием. Неотчужденность знаний связана и с другими затратами, которые проявляются постоянно. Вот некоторые из них:
    • Затраты времени на интеграцию новых сотрудников. При приеме нового сотрудника тратится время двоих: и новичка, и обучающего его более опытного сотрудника. Если же есть база знаний (описания бизнес-процессов и т.п.), то можно сократить по крайней мере затраты времени опытного сотрудника - ему меньше придется рассказывать.
    • Риск дисбаланса бизнес-процессов при их изменении. Как правило, серьезные бизнес-процессы затрагивают несколько подразделений компании, поэтому если одно подразделение решит оптимизировать этот бизнес-процесс у себя, то оно может существенно усложнить работу других подразделений. Часто требуемые изменения в действиях смежных подразделений невелики - проблема только в том, чтобы вовремя их известить об изменении (по уму - согласовать изменение бизнес-процесса с ними). Описание бизнес-процесса в базе знаний решает часть этой проблемы: теперь руководитель подразделения может хотя бы увидеть, с кем стоит согласовать изменение бизнес-процесса (связи могут быть весьма неочевидными).
    • Затраты времени на поиск информации об особенностях редко используемых бизнес-процедур. Обычный вопрос: "как работает этот документ?". Вопрос важен как для пользователя, так и для IT-службы, отвечающий за поддержку и доработку учетной или ERP-системы. Нужна документация, которая описывает то, что называется "учетной политикой" - некие экономические (или процедурные) предположения, принятые как описание среды. То, что не ясно из алгоритма, из самого кода программы. Это скорее ответ на вопрос "почему это так сделано". Это что касается вопросов программиста. У пользователя вопросы проще - как это работает, какие кнопки нажимать? Документация или контекстный help решают эту проблему как для пользователя, так и для программиста, причем это одна и та же документация. Критически важный вопрос - своевременность и простота обновления документации.
    • Затраты времени на поиск информации на поиск ответа на нечетко сформулированный вопрос. К примеру: "каким отчетом я могу посмотреть такую информацию?", "как можно сделать то-то?" и т.п. Принципиальной тут является открытость списка вопросов и нечеткость их формулировок. Решением является поиск по тексту базы знаний - при достаточном ее объеме что-либо полезное выловится.

    В статьях на тему менеджмента знаний встречается еще несколько целей базы знаний:
    • Поиск эксперта по проблеме среди сотрудников. Обычно используется в программистских фирмах - кто из сотрудников работал с такой-то библиотекой и т.п.
    • Быстрый поиск ответов на типовые вопросы клиентов. Особенно важно для сервисных служб. Такой функционал удобно интегрировать в CRM-систему.

    Не думаю, что последние два пункта актуальны для нашего завода.

    Определившись с целями создания базы знаний осталось определиться с тремя вещами:
    • Виды информации в базе знаний
    • Структура информации - рубрикация, категории, поиск и т.п.
    • Выбор конкретного программного решения

    Рассмотрим их по порядку.

    2. Виды информации в базе знаний

    В дальнейшем изложении я рассматриваю актуальные для нашего завода виды информации.

    2.1. Неспециальная или общая информация

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

    Скорее всего, этот список будет пополняться.

    2.2. Специальная информация

    Информация, имеющая свой круг пользователей (остальным просто не нужна):
    • Описание бизнес-процессов (см. п.1). Бизнес-процессы должны описываться единообразно, т.е. в одной-двух нотациях, чтобы быть сопоставимыми.
      Отдельный и весьма интересный вопрос, должны ли эти описания являться нормативными документами. Противоречие здесь в следующем: само понятие знания предполагает отражение того, как есть на самом деле и именно в этом ценность; нормативный же документ описывает должное и не всегда это должное достижимо, удобно или практично. Система менеджмента качества обязывает согласование всех изменений со всеми заинтересованными лицами, что не очень вяжется с понятием "знания". Это явно проблема, которую надо додумать.
    • Учетная политика. Здесь имеется в виду не столько бухгалтерская учетная политика, сколько предположения о внешней среде и обычных предположениях деятельности. К примеру: "все контрагенты делятся на две группы, для первой применяем одну модель планирования, для остальных - другую", "двуместный монтаж оснастки предполагает, что обе отливки одинаковы; теми редкими случаями, когда это не так, пренебрегаем и обрабатываем их вручную". Такие предположения можно выявить при анализе алгоритмов работы инфосистемы (если соответствующий процесс автоматизирован), но гораздо полезнее иметь их явное описание.
    • Описание инфосистемы, вернее всех входящих в нее компонентов. В частности, у нас есть описание нашей конфигурации 1С на нескольких уровнях, нижним из которых является описание элементарного объекта, его назначения и способов использования:
      • Справочник
      • Документ
      • Отчет

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

    Последняя категория информации выделяется по критерию авторства: только здесь имеет смысл автор материала. Этот вид информации годится для поиска экспертов среди сотрудников (см. п.1).

    3. Структура информации в базе знаний

    Имеется в виду структура организации информации. Электронный вид хранения информации позволяет структурировать информацию одновременно многими способами. Первый из них - по разделам. Вот, к примеру, как выглядит наш раздел информации по 1С (выдержки):
      Производственное планирование
        Общее устройство производственного планирования
          Нормативная производственная информация
          Техусловия
          Нормы материалов на производство продукции и техпроцесс
          Нормы вспомогательных материалов

        Баланс деталей и учет НЗП
        Баланс времени
        Основные производственные виды деятельности
          Стальное литье
          Цветное литье
          Электрошлаковое литье
          Механическая обработка
          Участок ИДЛ

        Потребность в материалах
          Отчеты норма/факт

        Планы производства
          Создание планов производства
          Понедельное перепланирование
          Сменные задания
          Отчеты план/факт

        Управление качеством продукции
          Техусловия
          Сертификаты
          Управление требованиями к проверке качества опытных отливок

      Бухгалтерский учет
        Учет затрат
          Прямые затраты и общепроизводственные расходы
          Коммерческие расходы
          Управленческие расходы

        Учет НДС
          Общий учет НДС
          Экспортный НДС

        Учет ТМЦ
        Учет оплаты труда
          Оплата труда как затраты
          Учет оплаты труда в механическом производстве
          Учет оплаты труда по заказам на производство

        Учет реализации
          Структура 90-х счетов
          Документы реализации по видам деятельности

      Управленческий учет

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

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

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

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

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

    4. Конкретное программное решение

    Прежде всего было решено, что это должен быть wiki-движок. Потому что:
    • Работает в любом браузере
    • Легко писать и править статьи
    • Хранятся все версии статьи
    • Легко развернуть на имеющихся серверах
    • Свободное (бесплатное) ПО
    • Народ работал с википедией и легко освоит построенную на таком же движке базу знаний

    Каждая статья имеет свой адрес, что позволило легко реализовать контекстный help в 1С и остальных системах автоматизации.
    Наиболее популярным движком является media-wiki, но мы выбрали doku-wiki, больше случайно, чем осознанно. Плюсы doku-wiki:
    • Все данные хранит в текстовых файлах, не требует базы данных
    • Очень просто освоить и начать использовать
    • Стандартный набор стилей позволяет распечатывать статьи без элементов управления и навигации (к слову, во многих media-wiki, что я видел в сети, это не настроено)

    Вместе с тем есть и минусы:
    • Достаточно бедная работа с картинками, невозможно вести историю версий картинки
    • Нет встроеннного механизма категорий, требуется устанавливать плагин
    • Встроенный поиск не учитывает русскую морфологию, требуется устанавливать плагин

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

    понедельник, 2 мая 2011 г.

    Инфодизайн табличных отчетов

    0.

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


    1. Адресаты

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

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

  • Готовность работать с большими объемами данных. Собственно, это их прямая обязанность.

  • Следование логике данных. Грубо говоря, они естественно продолжат ряд: «количество, цена...» и скажут «сумма»; более того, они ожидают увидеть в отчете либо только один показатель из них, либо все три. Следование логике данных выражается и в том, что если какие-то данные имеют совершенно разную природу, то и отчеты для их анализа должны быть различными; грубо говоря, количественные остатки материалов и суммы процентов по кредиту почти наверняка не встретятся в одном отчете для этой целевой группы.

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

  • Итак, это наша целевая группа. Она хороша тем, что немногочисленна и можно напрямую собрать пожелания. И к тому же предпочитает данные в виде таблиц, а не графиков и диаграмм. Большинство отчетов в виде таблиц, генерируемых инфосистемой, ориентировано именно на эту группу.
    Но рассмотрим и остальные группы и выделим их особенности.

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

    Об инфодизайне для этой группы пользователей я писать не буду, написано и без того много, желающих отсылаю к следующим сайтам и блогам:
    http://datatodesign.ru/
    http://edwardtufte.ru/envisioning-information/
    http://www.edwardtufte.com/tufte/
    http://themissinggraph.wordpress.com/
    и дальше по ссылкам оттуда.

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

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

  • Взгляд руководителя подобен взгляду лягушки: его интересуют только изменения. Чем выше руководитель, тем больше разнородных объектов в его подчинении. Он не может уделять всем объектам равное внимание (и не должен), к примеру, генеральный директор может пристально следит за одним-двумя основными направлениями бизнеса, наблюдая остальные по одному-двум основным показателям и оценивая «не упал ли объем продаж или прибыль». Если движения нет, продажи и прибыль на стабильном уровне, это направление его не интересует (оно подробно интересует директора по этому направлению, тут он ближе к исполнителю). Если же произошло резкое изменение, то это повод заинтересоваться. Как лягушка замечает насекомых — по движению.

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

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

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

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

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


    2. Чем мы можем управлять в табличном отчете

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

  • Состав данных таблицы

  • Ширина строк и колонок

  • Границы

  • Шрифт

  • Фон

  • Выключка в ячейке (размещение по левому/правому краю или по центру)

  • Ниже мы рассмотрим эти элементы более подробно.


    3. Экран и принтер

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

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

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

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


    4. Шрифт, форматы и выключка

    Таблица отличается от текста тем, что текст читается по строкам, а таблица больше по столбцам. При этом большую чать табличных данных составляют числа, а не слова. Шрифты с засечками семейства Антиквы (типа Times New Roman) хороши тем, что визуально объединяют строку, делая текст более гладким и удобным для чтения. Это очень хорошо для книг, полных текста, но совершенно неудобно для таблиц, которые читаются скорее по вертикали — тут засечки явно мешают. Для таблиц больше подходят гротески, шрифты без засечек (типа Arial).

    Большинство данных в таблице — числа, а наиболее частая операция при чтении таблицы — сравнение двух чисел, а сравнивать числа удобно, когда они расположены одно под другим. Из этого следуют такие правила:

  • Числа, подлежащие сравнению, лучше всего располагать в столбце, чем в строке;

  • Числа удобно читать, если они выровнены по правому краю, имеют одинаковое количество знаков после запятой и группы разрядов целой части разделены пробелом. Иные знаки разделения будут информационным шумом;

  • Если речь идет о целых числах из 1-3 знаков, то такие числа лучше всего размещать в ячейке по центру — при выключке вправо они будут прилепать к границе и хуже читаться (особенно числа из одного знака);

  • Числа, не предназначенные для сравнения (к примеру, номера) — выключка по центру;

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

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

  • Текст лучше всего форматировать по левому краю; выключка по ширине в таблицах неэстетична;

  • Текст можно форматировать по центру, если это буквенно-числовой номер или одно слово. Или когда важно само наличие этого короткого текста (к примеру, в реестре документов имя проверившего этот документ экономиста — тут важно не кто, а проверено или нет);

  • По вертикали выключка делается по середине высоты ячейки, но если в ячейке может быть многострочный текст (более 3 строк), то все ячейки стоит отформатировать по верхнему краю;

  • Данные, имеющие процентный формат, в большинстве случаев стоит выводить в целых процентах, со знаком % и выключкой по центру.

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

    Что касается использования шрифтов, то тут действуют такие правила:

  • Используйте одну гарнитуру шрифта для всего отчета. Мне хватает гарнитуры Arial;

  • Нормальный размер шрифта для табличных отчетов — 8-9 pt, более крупный шрифт обычно неудобен — слишком мало содержательной информации помещается на экране/странице;

  • Данные разного уровня (см. ниже) в таблице можно выделять размером шрифта (итоги крупнее, примечания совсем мелко) или жирным начертанием, курсив использовать не стоит, а для чисел — противопоказано;

  • Тех, кто использует в отчетах декоративные шрифты, надо бить по рукам так, чтоб потом неделю больно сидеть было!


  • 5. Состав данных таблицы

    Как было сказано в п. 1.а, колонки таблицы должны отражать логику данных. К примеру, если у нас в двух колонках даны плановые и фактические данные, то почти наверняка исполнителю важно видеть отклонение — план-факт или процент выполнения плана; если выводим в одном отчете и суммовые, и количественные данные, то почти наверняка нужно их отношение — средняя цена или средняя себестоимость, что оно там по смыслу.

    Форма отчета примерно в равной степени определяется как задачей отчета, так и структурой данных в инфосостеме. Иногда бывает, что структура данных в инфосистеме не совсем адекватно отражает структуру реальности, и встает вопрос, как сделать отчет: ориентироваться на структуру данных в инфосистеме или на некие эвристические правила («обычно у нас это соответствует тому, исключения редки»), то предпочтитение надо отдать структуре данных, оставив задачу сопоставления с реальностью (интерпретации) пользователю. Реальность может поменяться и ранее сделанные предположения о поведении реальности перестанут быть верными. Если мы пытаемся всякими хитрыми алгоритмами «найти смысл» в данных (что делает пользователь при составлении отчета вручную), то мы можем не заметить, что при изменении реальности наш отчет выдает правдоподобные, но неверные данные.

    Несколько полезных правил для таблиц:

  • Если в таблице есть суммовой столбец — внизу обязательно подбейте итог, это вполне осмысленная чиселка;

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

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

  • Если в таблице есть процент как отношение двух столбцов — выведите в итоге процент как отношение итогов, тут все вполне однозначно.


  • 6. Границы ячеек

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

  • Используйте как можно более тонкие границы — они должны лишь показать, где проходит граница, а не акцентироватьвнимание на ней;

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

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

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



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

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







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

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


    7. Методы выделения: фон и цвет

    Таблицы содержат много информации и важную или необычную информацию стоит визуально выделить. Основные виды выделяемой информации:

  • Более агрегированные данные — итоги и подитоги;

  • Подозрительные данные, с большой вероятностью говорящие об ошибке — как правило, отрицательные числа;

  • Данные, которые мы выделяем по каким-то правилам — полностью выполненные строки плана, отклонение более положенного и т.п.

  • Мы имеем несколько способов выделения, которые можно между собой комбинировать:
  • Простое или жирное начертание шрифта. Использование курсива или другого размера шрифта не рекомендуется, поскольку затрудняет сравнение числовых данных;

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

  • Выделение цветным фоном ячеек — рекомендуется использовать для выделения всей строки.

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

    Ниже приведены примеры двух трехуровневых отчетов.





    Здесь видны основные принципы построения многоуровневых таблиц:
  • Все данные имеют одинаковое число уровней, которые выделены цветом фона и отступом наименования (визуальное выделение уровня);

  • Цветовые обозначения продублированы в шапке таблицы;

  • Строки первого уровня отбиты сплошной линией границы сверху, а снизу — точечной линией; это показывает, что зеленые строки относятся к тем данным, что идут ниже них (итоги над данными);

  • Окончательный итог отбит двойной линией и выделен жирным шрифтом. В первой таблице строка окончательных итогов имеет более темный фон.

  • На второй таблице зеленые строки также имеют выделение жирным шрифтом. Это может быть удобно или неудобно — если мы сформируем те же отчеты без отображения третьего уровня, то обилие жирного шрифта в отчете станет визуальным шумом:





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

    Эти приемы инфодизайна можно перенести и на остальные таблицы, в которых мы хотим что-то выделить. К примеру:

  • Выделение цветом фона строк по какому-либо правилу (% выполнения плана >= 100% и т.п.);

  • Групировка строк в блоки — к примеру, в отчете по документам выводятся в единую таблицу все строки документов данного вида; можем применить полосатую раскраску, но красим не отдельные строки, а блоки строк, относящиеся к одному документу;

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

  • Вариантов таких выделений может быть очень много — главное определить заранее, какие критически важные данные нам надо выделять.

    Отдельно хочется сказать о цветовых схемах. Если хотите со всего маху дать в глаз пользователю, то посмотрите на те цвета фона, что предлагает Word для выделения текста. Или на те цвета, что расположены первыми на панели цветов Excel. Если ваш отчет называется «Джунгли в гости к нам», то самое оно.
    Если же вы заботитесь об эргономике ваших отчетов, то рекомендую приглушенные оттеночные тона. В иллюстрациях к этой статье я выбирал те цвета, которые не утомляют пользователя. Способ подобрать удачное сочетание цветов прост: прикиньте, одела бы ваша любимая женщина одежду в цветах вашего отчета? Можно у нее просто спросить :-)


    8. Расшифровки и инструменты анализа

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

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


    9. Пример одного идеально продуманного табличного отчета

    Я знаю один пример практически идеального табличного отчета — «Интерактивная оборотно-сальдовая ведомость» Сергея Барышникова в 1С:Бухгалтерии 7.7. Он формируется как обычная оборотно-сальдовая ведомость, но слева от кода счета расположен плюсик. Пр щелчке по нему предлагается выбрать вид расшифровки, после чего в строках расшифровки есть такие же плюсики, и эти данные можно расшифровывать дальше, и все это в пределах одной экранной формы отчета. На приведенной ниже иллюстрации я развернул обороты по счету 20.10 сначала по подразделениям, потом по видам номенклатуры, затем «Литье 12Х18Н9ТЛ» я развернул по статьям затрат, а статью Основные материалы развернул по корреспондирующим счетам.



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

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



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

    Как бы то ни было, и в инфодизайне табличных отчетов существуют свои произведения искусства.

    суббота, 19 марта 2011 г.

    Об услугах, хранимых на складе

    Ключевое отличие услуги от товара состоит в том, что услуга не может храниться, в книжках по маркетингу даже говорится, что оказание услуги идет одновременно с ее потреблением. В общем случае это верно. Типичный пример стандартной услуги - электроэнергия. Вроде бы вот они провода, включил лампочку - она светит, а счетчик вертится, считает киловатты. Ничего не хранится.
    А можно сделать эту услугу накапливаемой? Да, можно. К примеру, услуга по заправке аккумуляторов для электрокаров: привозят разряженные аккумуляторы, а забирают заряженные. Зарядка аккумуляторов совпадает по времени с потреблением услуги? - Нет, потому что момент потребления это когда забирают заряженный аккумулятор. То есть за счет наличия материального носителя - аккумулятора - услуга оказывается хранимой, т.е. приобретает черты товара.
    Реально я столкнулся с такой ситуацией по работе у нас на одном из участков мехобработки - туда привозят чужую (давальческую) продукцию для мехобработки или гидроиспытания. Для нас время производства услуги (учитывается по нарядам и вообще является драйвером распределения затрат) и момент возврата клиенту обработанной продукции и выставления акта об оказании услуг - могут вообще быть в разных месяцах. Еще в этой ситуации интересно то, что эти услуги - стандартизированы, их вполне можно учитывать по количеству (в отличие от ремонта электродвигателей - там услуги во многом индивидуальны, сильно зависят от вида поломки).
    В общем, при наличии материального носителя (давальческой продукции) услуга обретает черты товара. При этом она не тождественна этому носителю - одна и та же единица продукции может нести несколько услуг: мехобработка, гидроиспытания, УЗК и т.п.

    понедельник, 28 февраля 2011 г.

    Электронный архив - набросок проектной документации

    Есть у нас проблема: куча информации лежит в экселевских таблицах, текстовых документах и т.п. С этими файлами ведется двоякая работа:
    а) В один xls-файл несколько пользователей вносят информацию - маленькие кусочки, но ежедневно. В основном это ежедневная сводка для руководства. Работать с файлом по сети - бывает, Excel начинает виснуть. Да и пойди пойми, кто сейчас занял файл.
    Примечание: да, знаю, что по уму это не в файле хранить надо, а в базе данных. Возражения тут следующее: руководство очень часто меняет формат этой сводки, нужная информация должна умещаться на одной-двух страницах; так что разумной автоматизации не получается - поди пойми, что в следующий раз понадобится, а что мешать будет.
    б) Разные группы пользователей должны иметь разный доступ к документам, в основном быстро найти и открыть на просмотр. Рулить на уровне NTFS неудобно, к тому же если все в файлах, то имена у этих файлов как автор захочет. Неудобно, в общем.
    в) Случайная порча файла - случается; быстро восстановить предыдущую копию - а она хорошо если вчерашняя, а надо бы получасовой давности.

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

    1. Общие требования к ЭА

    Номинальная емкость системы - 1,000,000 документов, т.е. ID это шестизначное целое число с ведущими нулями. Реальная емкость, исходя из которой рассчитываем сейчас объемы и скорости - 10,000 документов.
    Система предназначена для хранения файлов, которые мы считаем бинарными - т.е. без анализа их содержимого. Реально там будут текстовые файлы (форматы txt, doc, odt, pdf, htm и т.п.), файлы электронных таблиц (xls, ods), всевозможные файлы инженерной графики и изображения (в основном отсканированные образы документов).
    Быстрая работа системы требуется с текущими версиями документов, добавление нового документа/новой версии, получение одной предыдущей версии документа. Работа с более ранними версиями может быть не быстрой - это гораздо более редкое событие.


    2. Хранение файлов в ЭА

    Файлы хранятся в папке на сервере, точнее - по подпапкам (не более 100 файлов в папке для ускорения работы с файлом). При помещении в ЭА файл переименовывается - новое имя совпадает с его ID в ЭА с ведущими нулями, расширение остается прежним.
    Версии файла нумеруются четырьмя знаками, имя файла версии имеет вид ID_VER, где ID 6 знаков, VER четыре знака. Версии файла, кроме предпоследней, могут храниться как в виде файла на сервере, так и в tar-архиве для экономии места.
    Для каждого файла (ID) может быть установлен режим хранения его версий - к примеру, храним одну ежедневную версию (на конец дня), или храним все версии возраста менее недели, потом оставляем из них ежедневные версии, а по истечении месяца - только еженедельные. В заархивированном виде лучше хранить те версии, которые уже предназначены для весного хранения (или можно их разбить по разным архивным файлам).


    3. ER-диаграмма ЭА

    24.50 КБ


    4. Функции ядра ЭА

    Все функции возвращают два результата: успешно или нет; в случае успеха - запрошенное действие (описывается ниже в каждой функции), в случае неудачи - код причины неудачи.

    В каждую функцию передается как один из аргументов Пользователь, от имени которого вызывается функция. Две цели: (1) проверить права, может ли данный пользователь выполнять эту функцию; (2) записать в БД имя пользователя как актора действия (там, где это требуется).

    ДобавитьНовыйДокумент(Файл /поток загрузки/)
    - возвращает ID файла в ЭА

    ВзятьДокумент(ID файла, Режим= просмотр/редактирование)
    - возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID
    - если файл взят на редактирование, то устанавливает в БД блокировку на него с указанием имени взявшего файл пользователя

    ДобавитьВерсиюДокумента(ID файла, Файл /поток загрузки/)
    - возвращает номер версии файла (пред. + 1)

    ОсвободитьЗанятыйДокумент(ID файла)
    - функцию может выполнять пользователь, взявший файл (не стал редактировать), а также пользователь со спецправами - менеджер. Пример: человек взял файл на редактирование и заболел, надо иметь возможность файл разблокировать пусть даже его работа потеряется.

    ПолучитьРеквизитыДокумента(ID файла)
    - возвращает список пар "реквизит/значение"

    УстановитьРеквизитыДокумента(ID файла, новые реквизиты)
    - функция для редактирования всяческих реквизитов файла в БД; новые реквизиты - список пар "реквизит/новое значение"

    ПолучитьВерсиюФайлаПоНомеру(ID файла, номер версии)
    - возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID и номером версии

    ПолучитьСписокВерсийФайла(ID файла)
    - список троек "номер версии/дата версии/статус (есть ли реально)"


    5. Взаимодействие с пользователями и приложениями

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


    6. Роботы ЭА

    В электронном архиве работают два робота (программы, запускающиеся по времени, раз в сутки).

    Робот-архиватор раз в сутки проверяет, не обновились ли указанные в листах-шаблонах файлы (и не появились ли новые), и добавляет новую версию в электронный архив. Требуется в основном для программных файлов на макроязыке 1С (формат txt, ert), места они занимают немного, а когда срочно исправляешь ошибку, можно и забыть сохранить предыдущую версию (особо полезно, когда исправление ошибки привело к возникновению новой - понять, что не так).
    Обратное действие к действиям робота - развернуть программные файлы в тех версиях, которые были на определенную дату. Это важно, если мы хотим восстановить старую архивную копию 1С - внутренний программный код сохраняется, а все внешние отчеты и программные модули надо хранить отдельно. Вот для этого робот-архиватор и нужен.

    Робот-хранитель чистит и упаковывает архив. Когда экономисты делают свои сводки, то им полезно иметь версии файла после каждой правки - чтобы в случае порчи быстро откатиться назад к последней нормальной версии. Но затем хранить эти версии (десяток за день) не надо - это чисто рабочий материал. Поэтому у каждого документа в ЭА мы указываем режим хранения - какие версии сколько хранить, к примеру "вечное" хранение только для последней версии за сутки, а все другие версии этих суток удаляются. Может, не сразу - через три дня. Да и хранить их в виде файлов слишком роскошно - старые версии сжимаем в архив. Все это делает робот-хранитель.

    ------------------------------

    Вот примерно такой первый набросок. По ходу дела буду додумывать. Хотя бы систему прав - как удобно сделать.

    суббота, 19 февраля 2011 г.

    ER-диаграмма трекера (основные таблицы)

    28.80 КБ

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

    12.08 КБ

    В общем, с конца октября трекер у нас работает для управления задачами отдела IT, уже более-менее нормально. Чего не сделано из того, что есть на первой ER-диаграмме:

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

    2. Подчиненные инциденты. Иногда одна задача дробится на несколько: к примеру, в заявке заказчика есть несколько деталей, сначала заявка рассматривается коммерческим директором и директором по производству целиком (они имеют право решить, что она нам не интересна), а потом доходит до отдела главного металлурга, где по деталям раздается нескольким технологам, дальше все движение идет по этим подзадачам. И в самом конце эти подзадачи опять собираются вместе и заказчику высылается протокол согласования цены по его заявке. Вот этот механизм - шла одна задача, потом разделилась, а потом снова собралась - пока не реализован. Идея такая: когда задача разделяется, то старая задача замирает без движения в некотором состоянии, и не может двинуться, пока все ее подчиненные задачи не придут в финальные состояния. При этом финальные состояния могут быть как положительными (технология оценена, есть калькуляция на деталь), так и отрицательными (данную деталь мы не можем произвести). Для этого предназначена ссылка "рамочный инцидент", но основная работа - в реализации логики движения. Пока не сделано.

    3. Основной исполнитель. Для задач отдела IT ясно, что основное состояние - "в работе". Исполнитель в этом состоянии - тот, кто на самом деле и выполнил эту задачу. Для движения заявок - ясно, что это технолог (при этом менеджер коммерческого отдела, притащивший эту заявку, уже виден как автор задачи). В общем, ловить этого исполнителя и потом анализировать по нему статистику - полезно, но не слишком критично. Пока не сделано.

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