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

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

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

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

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

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

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

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

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