От переводчика. Как часто вы обращаетесь к собственному домашнему фотоархиву? Конечно же, вы регулярно просматриваете свежие фотографии, иллюстрирующие совсем недавние события из вашей жизни. Еще вы посылаете их друзьям по электронной почте, размещаете в блогах и социальных сетях… Но проходит месяц — и воспоминания о событии стираются, и фотографии утрачивают былую значимость. Глядя на те же самые фото через год вы, возможно, вообще не вспомните, когда и зачем все это было снято. По мере разрастания фотоархива к вам приходит в голову вполне разумная идея: оставить лишь те фотографии, которые отражают действительно значимые события (например, свадьбу или защиту диссертации) и к которым вы будете время от времени обращаться​ Но чем больше времени проходит — тем менее осуществимым становится такой план. Вы просто физически не сможете просмотреть такое количество фотографий и определить, что нужно оставить, а что — удалить. Поэтому в такой ситуации вы, скорее всего, примете самое простое решение: приобретете жесткий диск большей емкости и перенесете фотоархив на него. Впрочем, к большинству фотографий вы все равно не будете обращаться.
Приведенный выше пример показывает, что частота обращения к документам со временем снижается. А теперь представьте себе, что речь идет не о домашнем фотоархиве, а об огромном массиве документов предприятия или организации. Для структурированного хранения документах в организациях внедряется специальное ПО — системы электронного архива (СЭА). В соответствии с определением, ставшим уже общепринятым и зафиксированным в стандарте MoReq, СЭА предназначены прежде всего для хранения бизнес-значимых документов. Однако часто бывает так, что в таких системах хранятся документы, утратившие свою значимость (например, видеозаписи выступлений на конференции по проблемам электронной коммерции, которые уже много лет как перестали быть актуальными или утратившие юридическую силу приказы и распоряжения, срок обязательного хранения которых давно истек).
Занимаясь разработкой и внедрением собственной системы электронного архива, мы часто сталкиваемся с тем, что вопросам экспертизы ценности переводимых в цифровой вид материалов в организациях в подавляющем большинстве случаев не уделяется внимания. В результате в систему вводится все подряд, без разбора. Ввод и хранение лишних документов всегда сопряжены с дополнительными временными и финансовыми затратами.
Как выстроить подход к управлению записями с учетом неизбежного уменьшения частоты обращения к документом? Как выработать политику архивного хранения с учетом темпов устаревания информации, характерных для нынешней эпохи?
Размышления на эту тему представлены в статье Сьюзан Гудман (США), специалиста по управлению записями Банка Америки.

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

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

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

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

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

От переводчика. Выбор ECM-системы — дело очень непростое. Публикаций, в которых описываются и сравниваются между собой различные программные решения — много, а вот лишенных рекламного характера материалов, представляющих собой беспристрастный анализ — мало. Сегодня мы хотели бы предложить вниманию наших читателей перевод статьи, написанной Нэнси Грэхем Морлэнд, сотрудницей Государственного архива штата Нью-Йорк. Автор занимает принципиально неангажированную позицию: в тексте даже не упоминаются названия каких-либо конкретных программных продуктов. Конечно, высказываемые в статье соображения во многом являются спорными. Но в то же время автор, документовед по специальности, смотрит на проблему выбора ECM-системы взглядом рядового пользователя и указывает на ряд моментов, на которые технические специалисты зачастую не обращают внимания.
Публикуя данный текст, мы также хотели бы пригласить читателей к обсуждению следующих вопросов: какие функции должно включать ПО для работы с электронными документами? каких функций, по вашему мнению, не хватает в используемых вами СЭД/СЭА.

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

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

Добрый день, Хабражитель!

Уверен с форматом nine-patch уже все давным-давно знакомы, вероятно даже не раз пользовались им в своих Android-проектах (а может даже и где-то ещё). Также о нём чуть менее года назад skkap писал небольшую статью о том, что это за формат, и «с чем его едят». Также он описал инструмент, предлагаемый для быстрого редактирования этих самых файлов.

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

Тут я и решил лично взяться за дело…

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

"У.М.Н.И.К." («Участник молодёжного научно-инновационного конкурса») — государственная программа поддержки молодых ребят с прорывными идеями. Скажу сразу, размер предоставляемой в рамках программы финансовой поддержки оставляет желать лучшего: всего 200 килорублей, выплачиваемых равными долями в течение одного года. Понятно, что на развитие проекта данной суммы никак не хватит, но на прибавку к зарплате молодой команде — вполне. Но важнее то, что в подобного рода конкурсах можно проверить на прочность себя и свой проект.

Об опыте моего участия в конкурсе «У.М.Н.И.К.» я и расскажу в этой статье.

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

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

В сжатом виде он выглядит так:

• Решить, кто наши докладчики и потенциальные участники, а также что, где и когда первые расскажут вторым
• Исчерпывающе и понятно написать о событии на своем сайте
• Анонсировать событие в СМИ и социальных сетях, пригласить клиентов и партнеров
• Заблаговременно открыть регистрацию участников
• Заранее получить презентации докладчиков и тезисы выступлений
• Обеспечить стабильно работающий интернет, звук, свет, ПО и другое оборудование
• Заснять доклады и дискуссии на видео
• Организовать досуг участников после мероприятия
• После события написать письмо с благодарностью участникам и докладчикам
• Ознакомить с материалами события тех, кто не смог принять в нем участие
• Составить детализированный отчет о событии
• Собрать фидбек и учесть все ошибки при организации следующего мероприятия

За подробностями, советами и примерами — под кат.

Заранее спасибо за дополнения! Самые актуальные добавлю в статью с указанием авторства — глядишь, так и составим универсальное пособие для организаторов событий.

Upd: дополнила статью советами из комментариев! Спасибо за помощь AndreiYemelianov, RGaifutdinov, mivanova, ollystar, Cancel, verbinka, mujaji.

От переводчика. Начало Нового года — прекрасный повод для подведения итогов и анализа дальнейших перспектив. Не так давно на сайте компании Doculabs нами была найдена интересная статья Джо Шепли (часть 1 и часть 2). Мы не могли не обратить внимания на эту статью: занимаясь разработкой и внедрением собственной системы электронного архива, мы стараемся отслеживать все актуальные мировые тенденции и изменения. Предлагаем несколько сокращенный перевод этой статьи вниманию наших читателей. Автор статьи размышляет о текущих трендах на зарубежном рынке ECM-систем. Приглашая наших читателей к дискуссии, предлагаем поразмышлять о том, какими будет тенденции развития ECM в России в ближайшие несколько лет.

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

Я хотел бы посвятить эту статью тому, зачем мы создали ООО совместно с СПбГЭТУ (ЛЭТИ) и что получили в итоге. Буду рад поделиться опытом, который, надеюсь, поможет реализовать ваши идеи.

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

Неудачи, с которыми приходится сталкиваться при внедрении ECM-решений, можно условно разделить на 3 группы:

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

По специфике своей профессиональной деятельности (разработка системы электронного архива, а также преподавание Enterprise content management в ВУЗе), я на протяжении последних 10 лет пристально изучаю ресурсы российского интернета по тематике электронного документооборота. Лично меня ситуация несколько удручает: с одной стороны, имеется много информации рекламного характера, с другой — мало независимой аналитики и образовательных ресурсов. Давайте попытаемся разобраться в этом тухляке и его причинах, проанализировав российские ресурсы.

Начнем с «независимых»

CNews

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

От переводчика. В настоящее время наша компания ведет активную работу по созданию и внедрению систем электронного архива проектной и конструкторской документации. Начиная публикацию цикла статей по данной тематике, в который войдут как оригинальные тексты, так и переводные материалы, мы хотели бы предложить вниманию наших читателей статью Лена Аспри, австралийского специалиста в области ECМ, посвященную проблемам использования ECM-систем для работы с чертежами. Статья написана в 2006 году, но затрагиваемая в ней проблематика не утратила своей актуальности и сегодня: автор ведет речь о специфике чертежей как особого вида документов, о проблемах совместимости форматов хранения технической информации, о практических аспектах внедрения ECM-решений для работы с чертежами.
При переводе текстов по ECM-проблематике неизбежно встает проблема адекватной передачи терминологии. Для многих терминов достаточно сложно подобрать адекватные русские эквиваленты. Поэтому в переводе данной статьи мы в некоторых случаях сознательно отказываемся от калькирования английских выражений и передаем их при помощи уже закрепившихся в русском языке оборотов. Так, в некоторых случаях мы передаем аббревиатуру ECM (Enterprise Content Management) как СЭА (система электронного архива). Мы считаем этот шаг вполне оправданным, так как: (1) системы электронного архива принадлежат к классу ECM-систем; (2) в статье чертежи рассматриваются как записи (records), а термин «системы управления записями» (ERM, electronic records management) в русском языке не прижился, и для обозначения ERM-систем в русскоязычных публикациях гораздо чаще употребляется термин СЭА.

Чертежи являются носителями важной информации во многих государственных и коммерческих организациях, однако им еще не уделяется должного внимания при внедрении СЭА.
Чертежи важны уже потому, что они представляют такие активы предприятия, как здания, машины и оборудование. Вместе с технической документацией чертежи описывают эти активы.
Чертежи вполне можно рассматривать как записи, свидетельствующие о проектной и конструкторской активности, но при этом специалисты в области управления информации нередко недооценивают их важность, что зачастую подвергает организацию серьезному риску.
Нередко бывает так, что чертежам не уделяют внимания до возникновения чрезвычайной ситуации. К сожалению, в таких ситуациях нередко имеет место и потеря капитальных активов (Прим. перев.: работа по систематизации и переводу в электронный вид документации Саяно-Шушенской ГЭС началась лишь после печально известных событий августа 2009 года. В это же время наша компания оцифровывала проектные и технические документы Богучанской ГЭС).

Хочу рассказать о семилетнем опыте ведения курса Enterprise content management (ECM) в питерском электротехническом универе.

Предмет: СЭД и ECM

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

Мы рассмотрим в данной статье доступность программного обеспечения в техническом ВУЗе. Речь пойдёт именно о ПО как предмете изучения.

Не так давно я сам был студентом СПбГЭТУ «ЛЭТИ», а теперь работаю в IT-компании и преподаю в родном ВУЗе. Вместе с этим изменился и мой взгляд на учебный процесс в целом и на проблему комплектования учебных классов программным обеспечением в частности. Сегодня я попытаюсь рассмотреть её с трёх сторон: с точки зрения студента, преподавателя и производителя ПО.

Добрый день, Хабражитель!

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

Сегодня же я представлю на Ваш суд «последний рубеж» погружения во все те возможности, которые предлагает нам Swing – создание своего Look and Feel класса, а также всего того, что потребуется по ходу дела.

Сразу скажу — если Вы хотите взяться за написание своего примера, а не просто «подсмотреть» пару интересных моментов — будьте готовы угробить потратить на это дело много времени, если Вы конечно собираетесь выпустить что-то более-менее живое и юзабельное в любых приложениях в качестве «обёртки», а также собираетесь в дальнейшем поддерживать созданный вами LaF.

Но даже если Вы не собираетесь делать свой LaF – советую всё же ознакомиться с содержанием. Уверен Вы найдёте много нового и интересного. И даже, возможно, поймёте в чём был корень той или иной интерфейсной проблемы, которая, вероятно, мучала Вас долгие месяцы и годы.

Tip: Если Вы не ещё не знакомы с графикой и Swing в Java более-менее тесно — советую сперва перечитать несколько статей на тему (к примеру оффициальный туториал, статью по Swing от Skipy или же мои предыдущие вводные статьи).

Добрый день, Хабражители!

Сегодня я опять постараюсь привлечь Ваше внимание к некоторым сторонам и тонкостям работы с графикой в Java. Я уже кратко описал в предыдущей статье некоторые доступные средства и способы создания компонентов и UI, но это лишь вершина айсберга. Именно поэтому я хочу уделить отдельное внимание (и статью) именно работе с графикой. Естественно имеется в виду Graphics2D – Java 3D это большая отдельная тема (возможно о ней еще пойдет речь в дальнейшем, но не сегодня).

Итак, из предыдущей статьи Вам уже должны быть известны некоторые основы построения компонентов — постараемся расширить эти знания.

Начнем с того, что если рассматривать любой компонент с точки зрения MVC – он состоит из 3ех частей:
Model – модель, которая хранит в себе данные о состоянии компонента и на основе которой строится внешний вид
View – непосредственно визуальное отображения компонента
Controller – отвечает за управление компонентом (события от клавиатуры, мыши и прочих устройств ввода)

Фактически, все стандартные компоненты Swing построены по паттерну MVC. К примеру в JButton — ButtonModel отвечает за поведение и состояние кнопки (Controller и Model), а ButtonUI в свою очередь за внешнее её представление (View). В итоге на долю самого класс JButton практически ничего не остаётся. Речь пойдет по большей части о реализации внешнего представления компонентов (View), и если уточнять — о Graphics2D, на основе которого, фактически, рисуется весь интерфейс.

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