Цели и структура корпоративной 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, что я видел в сети, это не настроено)

Вместе с тем есть и минусы:

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

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

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

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ТЛ» я развернул по статьям затрат, а статью Основные материалы развернул по корреспондирующим счетам.



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

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



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

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

Поехали!

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

Скажу сразу - бухгалтерия и производственное планирование/диспетчирование у нас сделаны на 1С:7.7. Причины такого выбора:
1. Исторические - сначала фирма занималась только металлоломом, там все было автоматизировано на 1С. Потом с появлением литейных цехов постепенно система наращивалась и дописывалась - эволюционировала, в общем;
2. Специфические - металлургическое производство весьма специфично, так что стандартных решений (типа MRP II для машиностроительного производства) нет или они стоят столько, что заводу на те же деньги можно купить новую производственную линию. С другой стороны, эта специфика не связана с большой сложностью, так что слабые вычислительные возможности 1С вполне достаточны для возникающих задач;
3. Персональные - имеющийся персонал знает 1С, так что хоть со стороны освоенности инструмента нет проблем.
В общем, на чем-то другом можно было бы сделать и круче, но 1С для этой задачи достаточно, и будет достаточно еще несколько лет.

На первых порах буду писать о двух проектах:

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

Ну и еще одна тема - алгоритмы производственного планирования в привязке к нашему производству.