На сайте ведутся работы Корпоративная база знаний - Ваш опыт | Решение рекламных и бизнес-задач | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » Решение рекламных и бизнес-задач

Корпоративная база знаний - Ваш опыт

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2009-07-13 18:06:15
Катерина Аврутина (Дробот) » Всем

Уважаемые Коллеги!

У нас в компании давно назрела необходимость создания такого ресурса как корпоративная база знаний, в которой будет храниться следующая информация: 

  1. Регламентирующие документы по всем должностям в компании. Все инструкции, стандарты, процедуры, алгоритмы, описания бизнес-процессов, шаблоны документов / журналов / отчетов - все, чем пользуются сотрудники в процессе работы. Необходима возможность комментирования документов для того, чтобы сотрудники могли оставлять заметки / замечания / рацпредложения и проч. Опираясь на комментарии, мы будем вносить необходимые изменения в документы.
  2. Справочные документы о компании для внутреннего пользования - описание компании (чем занимается), история развития, долгосрочные цели, текущие задачи (на ближайший год, квартал, месяц). Эта информация нужна текущим сотрудникам компании в качестве ориентира для согласованности действий и понимании своей роли в компании. Эту информацию каждый раз доносят до сотрудников руководители отделов в процессе планирования и постановки задач, ее мы каждый раз порционно даем новым сотрудникам при приеме на работу. Хотелось бы сэкономить время на разъяснения.
  3. Библиотека компании - реестр всех обучающих материалов в компании (бумажные книги, аудио книги, видео семинары, лекции и проч.). Общий список с отметкой о наличии и сроках возврата для материальных носителей, инструкцией о получении для электронных копий. Необходима возможность комментирования - чтобы сотрудники могли оставить свои впечатления и рекомендации. Необходима функция поиска по всем рекомендациям определенного сотрудника.
  4. Интересные статьи, обсуждения и дискуссии, с других Интернет-ресурсов. Сейчас обмен этими материалами происходит стихийно в режиме "Ты видел...? А ты читал...?" Хотелось бы сделать подобный обмен централизованным, с возможностью комментирования. Наиболее интересные материалы выносить на обсуждение в рамках еженедельных планерок/докладов (есть у нас такая практика).
  5. Новости по отрасли - размещение новостной ленты (сборка из тех новостных ресурсов, которые мы отслеживаем) с возможностью комментирования.
  6. Сообщения о нововведениях, новости по компании - информация для внутреннего пользования.

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

Вопросы у меня следующие:

  • Кто уже сталкивался с внедрением или использованием подобного ресурса у себя в компании - поделитесь опытом, пожалуйста. Что обязательно стоит предусмотреть, а на какие грабли лучше не наступать?
  • С учетом того, что данная система строится для внутрикорпоративного использования и будет доступна в рамках сети INTRANET, то каким образом мы затрагиваем вопросы авторского права по каждому из разделов? И как следует поступать правильно изначально?
  • На каком программном обеспечении имеет смысл строить подобную систему? Мы пока остановились на TikiWiki - это движок, на котором реализована Википедия. Есть ли достойные альтернативы и если да, то какие? 

С уважением,

Катерина

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-13 18:23:26
Андрей Жуков » Катерина Аврутина (Дробот)

Добрый день!

1. Я сделал на ANY. Сделал авторам "ANY-TRADE" предложение, от которого они не смогли отказаться. И они мне сделали сетевую "пустую ANY", но с возможностями заводить свои разделы и проч.

 

2. Wiki - хороший движок. Просто мне было удобно добавить к "ANY-TRADE" свои материалы и - таким образом - иметь сразу одну большую библиотеку.

 

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-13 18:25:26
Павел Друбич » Катерина Аврутина (Дробот)

С учетом того, что данная система строится для внутрикорпоративного использования и будет доступна в рамках сети INTRANET, то каким образом мы затрагиваем вопросы авторского права по каждому из разделов? И как следует поступать правильно изначально?

Надо Вам завести (независимо даже от этой Вашей штуковины) "Положение о служебном Произведении" и больше не переживать на эту тему.

 

С пожеланиями,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-14 15:10:37
Серафим » Катерина Аврутина (Дробот)

Уважаемая Катерина!

TikiWiki - это движок, на котором реализована Википедия.

Википедия работает на движке MediaWiki.

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-14 15:59:01
Катерина Аврутина (Дробот) » Андрей Жуков

Уважаемый Андрей!

Благодарю Вас за ответ, мне очень интересен Ваш опыт.

Что касается ANY, то этот вариант я не рассматривала по двум причинам:

  1. Я не вижу в ней возможности комментирования сотрудниками материалов.
  2. Исторически так сложилось, что когда мы купили вначале кейс Employ, а потом и пакет ANY, в них не было предусмотрено использование на терминальном сервере. Все наши сотрудники работают в терминале - это очень удобно, на локальных машинах даже офис не установлен. Поэтому фактически оболочкой мы не пользуемся совсем и не можем оценить ее преимущества и недостатки по сравнению с той же Wiki.

Андрей, мне был бы очень полезен Ваш ответ на следующий вопрос:

Кто уже сталкивался с внедрением или использованием подобного ресурса у себя в компании - поделитесь опытом, пожалуйста. Что обязательно стоит предусмотреть, а на какие грабли лучше не наступать?

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-14 16:22:39
Катерина Аврутина (Дробот) » Павел Друбич

Уважаемый Павел!

Надо Вам завести (независимо даже от этой Вашей штуковины) "Положение о служебном Произведении" и больше не переживать на эту тему.

 

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

Что должно быть в этом Положении, чтобы это давало нам возможность не переживать на тему правомерности использования материалов при наполнении разделов 4 и 5 базы знаний? 

 

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-14 16:35:55
Катерина Аврутина (Дробот) » Серафим

Уважаемый Серафим!

Википедия работает на движке MediaWiki

Сожалею, если ввела Участников Форума в заблуждение и это действительно критично. Я не настолько хорошо разбираюсь в движках и их отличиях (если честно, совсем не разбираюсь :)) Наш IT-отдел для этой задачи выбрал TikiWiki, в качестве примера "как это будет" привели Википедию, вот я не нее и сослалась.

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

С уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2009-07-14 17:55:11
Андрей Жуков » Катерина Аврутина (Дробот)

Уважаемая Катерина!

Уже давно есть терминальная версия  "ANY". Есть терминальная версия "RI-Employ". И без ограничения числа Пользователей. У меня ANY тоже раньше была локальной, я проапгрейдил.

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

Как это не могут комментировать? Нажимаете на кнопку "Создать мой вариант", комментируете, оригинал сохраняется, версионность тоже есть. Кроме того, обмен проектами.

Кто уже сталкивался с внедрением или использованием подобного ресурса у себя в компании - поделитесь опытом, пожалуйста. Что обязательно стоит предусмотреть, а на какие грабли лучше не наступать?


Изначально для меня было важно устранить файл-сервер, как источник бардака. Мне надо было так, чтобы файл-сервера не было, а функция его выполнялась. Мои "грабли" - это "проводник Windows". Где ,как ни разгранивай доступ, энтропия растет... ну, очень быстро.

Поэтому был неизбежен взгляд в сторону Web-технологий. ANY в этом смысле мне понравилась тем, что позволяет создавать/сохранять web-проект, как файл и потом обмениваться этими проектами, а также тем, что проект, созданный, например, в разделе "Поставка", при его загрузке на другой компьютер, сохранится и на другом компьютере только в разделе "Поставка" - т.о. - невозможно создать беспорядок.

И еще. Мне представляется, что основная проблема базы знаний - это не то, на каком движке она выполнена, а то как она наполняется. Если смотреть "со стороны компании", то качественное наполнение - очень трудоемкая работа. Я писал часть сам, я вычитывал за сотрудниками, я вынужден был их учить и т.д. ... Новичков, опять же, учить. Поддерживать нормальный контент - тяжелая работа.

Я подумал, что надо жить иначе: небольшую часть - да - делать самим и качественно. А потом меняться и покупать готовое. Т.е., "собственное" + "покупка" + "обмен" дает шанс, а иначе получится, как с сайтами. Тысячи фирм завели себе сайты, а дальше... Висят по нескольку страниц "Добро пожаловать на фирму ___________" и т.д.

Такие дела.

Успеха,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-14 18:02:44
Павел Друбич » Катерина Аврутина (Дробот)


Новости по отрасли - размещение новостной ленты (сборка из тех новостных ресурсов, которые мы отслеживаем) с возможностью комментирования.

Если Вы берете новость у внешнего источника, надо связаться и договориться.


Сообщения о нововведениях, новости по компании - информация для внутреннего пользования.

Это не объекты авторского права.

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

Пусть подпишут. Ибо, сказано: "Не введи в искушение и избавь от лукавого"

С пожеланиями,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-15 00:45:26
Катерина Аврутина » Андрей Жуков

Уважаемый Андрей!

Как это не могут комментировать? Нажимаете на кнопку "Создать мой вариант", комментируете, оригинал сохраняется, версионность тоже есть. Кроме того, обмен проектами.

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

Изначально для меня было важно устранить файл-сервер, как источник бардака. Мне надо было так, чтобы файл-сервера не было, а функция его выполнялась. Мои "грабли" - это "проводник Windows". Где ,как ни разгранивай доступ, энтропия растет... ну, очень быстро.

 

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

И еще. Мне представляется, что основная проблема базы знаний - это не то, на каком движке она выполнена, а то как она наполняется. Если смотреть "со стороны компании", то качественное наполнение - очень трудоемкая работа. Я писал часть сам, я вычитывал за сотрудниками, я вынужден был их учить и т.д. ... Новичков, опять же, учить. Поддерживать нормальный контент - тяжелая работа.

 

Я подумал, что надо жить иначе: небольшую часть - да - делать самим и качественно. А потом меняться и покупать готовое. Т.е., "собственное" + "покупка" + "обмен" дает шанс, а иначе получится, как с сайтами. Тысячи фирм завели себе сайты, а дальше... Висят по нескольку страниц "Добро пожаловать на фирму ___________" и т.д.

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

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

Руководство...
Стандарт...
Процедура...
Инструкция...
Методика...
Перечень...
Реестр...
... и много других умных слов (да простит меня Уважаемая Редакция), я пожала плечами и сказала: "Круто, но мы отложим это до лучших времен". Со временем у нас и так начали появляться все эти документы, без привязки к функционалу ANY, однако до полного перечня нам еще копать и копать.

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

Если же говоря "поддерживать нормальный контент" Вы имеете в виду нечто совсем иное, поясните свою точку зрения, пожалуйста.
 

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-15 07:52:56
Андрей Жуков » Катерина Аврутина

Добрый день!

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

Когда поручаешь кому-либо подготовить документ, то лучше, когда последующие правки вносятся в текст документа + есть возможность откатываться на версии. Так получается быстрее и качественнее. И ответственность видна. Но я согласен с тем, что корпоративный Форум полезен в любом случае. Т.е., не "или-или", а "и-и".

У меня корпоративный Форум был и раньше - т.е., это отдельная система. Мы и раньше общались на Форуме, и сейчас общаемся, а на документ ANY теперь ссылаемся. По своему, это удобно: под документом нет никаких портянок с обсуждениями. Последний документ = всегда самый актуальный. Сотрудники не отвлекаются, когда просто обращаются за шаблоном и т.д. Все-таки, архив это эталонное место.

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

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

  • достаточно много времени будет уходить даже на то, чтобы их просмотреть по заголовкам (а Web-интерфейс с навигацией, поиском и возможностью накопления избранных ссылок все это упрощает);
  • Вы не можете быть уверены в том, что Ваш стандарт на хранение документов действительно выполняется = для того, чтобы действительно мониторить его выполнение, Вам потребуется время, превышающее суточное. И это время будет расти. И даже в этом случае (если будете мониторить), Вам не уследить за тем корректно ли (относительно стандарта) содержание каждого нового документа (и даже затем корректен ли его заголовок), не уследить даже за тем не сохранили ли сотрудники (в т.ч., Ваш директор) документ с названием "Инструкция по работе с инкассатором" в папку "Тренинги продавцов" (во-первых, ведь даже в голову не придет проверить именно это, во-вторых сколько таких "сохранений" происходит в день откуда мы знаем = получается надо проверять все, а значит = см. выше). А на Web-платформе я просто вижу текущие обновления, заголовки которых выползают на ленту и все ОК. Плюс ANY не дает возможности сохранять не там, где создали.
  • Разграничением доступа перечисленное Выше не решается. Во-первых, потому что люди обмениваются данными - иначе они не могут работать. Во-вторых, даже в "узкой зоне" (при доступе в несколько специализированных папок) тоже вырастет беспорядок. А проверять надо "кучу мелких беспорядков" = что толку...
  • ..... и еще N пунктов .......

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

    А Вы начните. И сразу почувствуете, насколько идеализированное это представление.

    "Круто, но мы отложим это до лучших времен". 

    А я сказал: "Круто. Поэтому сразу беру себе". Все, что мне нравится, я не откладываю. Зачем? Сами по себе лучшие времена не приходят.

    С Уважением,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-15 15:01:28
Михаил Опанасенко » Андрей Жуков

Андрей!

Вы, конечно, правы. У меня задачи похожие.

А, все-таки, вот я представил себе ANY, как Википедию "Фирма" (даже в Сети Глобальной), где можно было бы заводить и свои эккаунты, и пользоваться общей базой знаний + сразу много людей редактировало бы.

Ведь очень было бы удобно. Как бы, выращивал себе фирму на ресурсе.

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-15 15:45:57
Катерина Аврутина (Дробот) » Павел Друбич

Уважаемый Павел!

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

  1. Запрашивать разрешение на размещение материалов оптом - количество источников ограничено, и единоразовое получение разрешения у каждого из них вполне приемлемо. Несомненный плюс этого решения - можно приводить текст материала целиком (разумеется, с корректной ссылкой на первоисточник), и даже если по какой-то причине материал перестанет быть доступным в сети, в нашей базе знаний он останется. Минусы: у меня большие сомнения по поводу возможности получения такого оптового разрешения (кстати, хотелось бы по этому поводу узнать мнение Уважаемой Редакции). И даже если часть источников дадут такое разрешение - у кого-то мы его или не получим, или не получим ответа вообще.
  2. Размещать в базе не тексты целиком, а ссылки на материалы (или загружать текст во фрейм) в сети для ознакомления сотрудников и последующего комментирования. Это не настолько удобно, как в первом случае, однако целиком правомерно, на мой взгляд (или я ошибаюсь?).

Как сохранить преимущества первого варианта и вместе с тем максимально упростить процедуру публикации материалов (и по времени выполнения, и по числу операций)?

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

С уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2009-07-15 17:13:23
Катерина Аврутина (Дробот) » Андрей Жуков

Уважаемый Андрей!

Когда поручаешь кому-либо подготовить документ, то лучше, когда последующие правки вносятся в текст документа + есть возможность откатываться на версии. Так получается быстрее и качественнее. И ответственность видна. Но я согласен с тем, что корпоративный Форум полезен в любом случае. Т.е., не "или-или", а "и-и".

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

На этом же Форуме у нас размещены памятки, стандарты и правила работы по заказам для наших сотрудников и сотрудников Заказчика - там же обсуждается необходимость внесения корректировок.

У меня корпоративный Форум был и раньше - т.е., это отдельная система. Мы как на нем общались, там и общаемся, а на документ ANY теперь ссылаемся. По своему, это удобно: под документом нет никаких портянок с обсуждениями. Последний документ = всегда самый актуальный. Сотрудники не отвлекаются, когда просто обращаются за шаблоном и т.д. Все-таки, архив это эталонное место.

Вот именно потому, что архив - это эталонное место, я и озадачилась необходимостью создания базы знаний. Форум отдельно, база отдельно.

 

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

 

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

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

  1. полезные документы по проектам, которые должны храниться длительное время
  2. полезные документы по проектам, которые следует удалять по истечению определенного периода
  3. всяческий мусор

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


В итоге мы имеем:

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

Что касается недостатков единого дискового пространства, то:

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

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

Вы не можете быть уверены в том, что Ваш стандарт на хранение документов действительно выполняется = для того, чтобы действительно мониторить его выполнение, Вам потребуется время, превышающее суточное. И это время будет расти. И даже в этом случае (если будете мониторить), Вам не уследить за тем корректно ли (относительно стандарта) содержание каждого нового документа (и даже затем корректен ли его заголовок), не уследить даже за тем не сохранили ли сотрудники (в т.ч., Ваш директор) документ с названием "Инструкция по работе с инкассатором" в папку "Тренинги продавцов" (во-первых, ведь даже в голову не придет проверить именно это, во-вторых сколько таких "сохранений" происходит в день откуда мы знаем = получается надо проверять все, а значит = см. выше). А на Web-платформе я просто вижу текущие обновления, заголовки которых выползают на ленту и все ОК. Плюс ANY не дает возможности сохранять не там, где создали.

 

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

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

Разграничением доступа перечисленное Выше не решается. Во-первых, потому что люди обмениваются данными - иначе они не могут работать. Во-вторых, даже в "узкой зоне" (при доступе в несколько специализированных папок) тоже вырастет беспорядок. А проверять надо "кучу мелких беспорядков" = что толку...

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

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

А Вы начните. И сразу почувствуете, насколько идеализированное это представление.

Начать что?

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-17 16:31:18
Андрей Жуков » Катерина Аврутина (Дробот)
Добрый день!

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

Допустим мы его не нашли. Где же он? Допустим мы обнаружили несколько файлов с одним названием в разных папках. Как быть?

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

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


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

А скопировать документ не в ту папку (т.е., размножить его по разным папкам) можно?

У нас люди не обмениваются данными, они их сохраняют в кучу специализированных папок

Было бы идеально, если бы не было специалированных папок вовсе. 

Начать что?

Вести базу знаний.

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-17 18:33:10
Катерина Аврутина (Дробот) » Андрей Жуков
 Уважаемый Андрей!

Благодарю Вас за вопросы

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

Допустим мы его не нашли. Где же он?

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

1. Стандарт названия медиаплана на стадии трансляции рекламной кампании выглядит следующим образом:

[ДатаНачала]_[ДатаОкончания]_[НазваниеКонтрагента]_[НазваниеРК].xls

Соответственно, вот примеры названия файлов с медиапланами:

090713_090811_КиевскаяРусьБанк_Переваги.xls

090716_090814_ЦифФотоЭкспресс_Цоколь-Громче.xls

090715_090808_Маг_Розыгрыш-Край.xls

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

[НомерЗаказа]_[ДатаНачала]_[ДатаОкончания]_[НазваниеКонтрагента]_[НазваниеРК].xls

2. Шаблоны всех документов имеют в названии структурный элемент с ключевым словом "Шаблон".

Соответственно, вот примеры названий файлов с шаблонами документов:

Шаблон_БП.xlt

Шаблон_Контакты.xlt

Шаблон_Журнал_Заказы и Заявки.xlt


3. Все документы по каждому Контрагенту имеют в названии структурный элемент с сокращенным названием Контрагента.

 
4. и т.д.


Теперь, при поиске конкретного документа по диску, нужно определить по какому параметру в названии его лучше всего искать и произвести поиск.

Допустим мы обнаружили несколько файлов с одним названием в разных папках. Как быть?

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

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

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

Шаблоны документов лежат в каталоге "Библиотека". Туда документы попадают только после моего утверждения, а у всех сотрудников компании доступ в этого каталог только на чтение.

А скопировать документ не в ту папку (т.е., размножить его по разным папкам) можно?

Можно, но зачем? (если отбросить сознательное копирование по разным папкам, т.е. вредительство)
 

Было бы идеально, если бы не было специалированных папок вовсе.

Под специализированными папками я понимаю те, у которых есть назначение

- личные папки сотрудников

- рабочие папки текущих заказов (один заказ = одна папка)

- рабочие папки текущих проектов

- и т.д.

- "Рабочий стол" и "Мои документы" - это тоже в своем роде специализированные папки.

а Вы что понимаете?

Начать что?

Вести базу знаний.

Андрей, боюсь у Вас сложилось неверное впечатление о моей задаче. Она не в том, что я планирую начать вести базу знаний и раздумываю на каком движке ее построить. Она в том, что у нас уже есть приличное количество материалов по разделам 1-3 и хотелось бы сделать это хранилище на Web-технологии, т.к. хранение на диске неудобно для их использования. А раз уж я занимаюсь этой задачей, то хотелось бы ее расширить, добавив пункты 4-6.

С уважением и благодарностью за участие,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-18 12:21:32
Андрей Жуков » Михаил Опанасенко

А, все-таки, вот я представил себе ANY, как Википедию "Фирма" (даже в Сети Глобальной), где можно было бы заводить и свои эккаунты, и пользоваться общей базой знаний + сразу много людей редактировало бы. Ведь очень было бы удобно. Как бы, выращивал себе фирму на ресурсе.


Да, как Вам сказать, Михаил,... Оно, конечно, красиво. Но в реальности,
  • 90% процентов Посетителей только читали бы и качали,
  • 5% процентов писали бы ерунду и спрашивали (не читая, при этом, Памяток и формуляров), 
  • 3% "выращивали" бы на своем закрытом ресурсе и зажиливали обмен", 
  • 1% "выращивали" бы и не жилились, но это не представляло бы ценности,
  • 1% - "выращивали" бы то, что обладает ценностью и не жилились бы ... Но это был бы тот самый 1%, которого Вы такой идеей лишили бы дохода. И который выложил бы основной массив и ничего не получил бы взамен.

Разве нет?

C Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-18 15:48:44
Андрей Жуков » Катерина Аврутина (Дробот)

Добрый день!

Она в том, что у нас уже есть приличное количество материалов по разделам 1-3 и хотелось бы сделать это хранилище на Web-технологии, т.к. хранение на диске неудобно для их использования. А раз уж я занимаюсь этой задачей, то хотелось бы ее расширить, добавив пункты 4-6.

Хранится что бы то ни было все равно на диске, но я понял, что Вы имеете в виду, что парадигма хранения "папки - файлы"  неудобна для использования. Здесь спорить нечего, согласен.

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

Например,

предположим, что файл 090713_090811_КиевскаяРусьБанк_Переваги.xls хранится в архиве в папке Контрагента "КиевскаяРусьБанк", а файл 090716_090814_ЦифФотоЭкспресс_Цоколь-Громче.xls хранится в папке Контрагента "ФотоЭкспресс_Цоколь".

Представим себе модельные ситуации (возможно, у Вас их не бывает, но это пока и может быть именно для этих документов не бывает и т.д. - отнеситесь, как к модельному примеру):

Ситуация 1: Вам потребовалось создать папку "Кампании 2009 года", "Кампании 2008 года". При этом, потребность хранить кампании в папках контрагентов никуда не пропала.

Ситуация 2: Вам потребовалось создать специализированные папки "Кампании банков", "Кампании фотосервисов", "Кампании продуктовиков" и т.д. . При этом, потребность хранить кампании в папках контрагентов, а также в папках хронологических никуда не пропала.

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

Ситуация 4: Вы собираете методические обобщения. Например, Вы накапливаете определенные схемы ротации роликов с тем, чтобы улучшать эфективность. Одна схема (Название) была применена во время кампании 090713_090811_КиевскаяРусьБанк_Переваги.xls, другая схема (Другое название) была применена во время кампании 090716_090814_ЦифФотоЭкспресс_Цоколь-Громче.xls, а во время кампании 090715_090808_Маг_Розыгрыш-Край.xls была применена тоже первая схема (Первое название). И у Вас возникает потребность создать методическую корневую папку "Схемы" (например), а в ней разместить папки конкретных схем, в которых хранятся примеры этих кампаний.

При этом, потребность хранить кампании в папках контрагентов, в папках хронологических, в папках отраслевых и в папках тематических никуда не пропала.

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

090713_090811_КиевскаяРусьБанк_Переваги

090716_090814_ЦифФотоЭкспресс_Цоколь-Громче

090715_090808_Маг_Розыгрыш-Край


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


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

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

А еще лучше не в папке, а на Web-сайте (под которым база), где каждый документ представляет собой материал, выложенный на страницу, имеющую один адрес (урл), по названию которого вовсе не надо определять, что это (т.к., мы это видим, открыв страницу). Может называться httр://our_mind/193445 (как-то так). (Пример. Мы же ищем материалы этого Форума, не читая его длинные урлы). И если все это так, то незачем их так строго именовать (090713_090811_КиевскаяРусьБанк_Переваги).

И, выложив на Web-страницы наши документы, мы делаем сайту навигацию. Например, такую (продолжая вышеприведенный пример):

  • Схемы наших Кампаний
  • Кампании по отраслям
  • Кампании во времени
  • Кампании по Клиентам
  • и т.д., или иначе, как хотите ......

Далее, заходя в любой раздел, мы из любого контекста выходим на документ про кампанию банка "Киевская Русь". При этом, он остается в единственном экземпляре и имеет единственный адрес, помнить который не обязательно. Например, httр://our_mind/193445 .(Или находим его поиском).

Несложно заметить, что вдобавок мы устранили возможность захламления. Ибо, никто не размножит страницы сайта. А если у нас есть еще и версионность, то и содержимое сохраним. Сотрудники общаются ссылками, документов не пересылают. Если надо создать следующую версию, создают. И полный порядок.

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

С Уважением,

P.S. Частность:  Допустим Вы бы решили сохранить это мое сообщение в своей корпоративной базе знаний, которая построена в модели "папки-файлы".

  1. Как бы Вы его назвали?
  2. В какую бы папку Вы его положили?
  3. Как бы Вы его ассоциировали с упомянутыми выше документами?
  4. Если бы кто-то захотел прочитать и сообщение, и документы, на которые есть ссылка, сколько действий ему надо было бы совершить, чтобы все собрать?

Используя же Web-технологию, над первыми двумя вопросами Вам бы думать не пришлось вовсе. В самом сообщении были оставлены гиперссылки и - т.о. - снялись бы п.3. и п.4.

P.P.S. Я здесь не коснулся "библиотеки", но принцип тот же.
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-19 13:51:53
Катерина Аврутина » Андрей Жуков

Здравствуйте, Андрей!

Хранится что бы то ни было все равно на диске,

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

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

Вот именно эта ситуация, только в применение не к рабочим файлам, а к документам каталога "Библиотека" и привела меня к необходимости перехода на Web-интерфейс, т.к. одни и те же шаблоны и стандарты могут использоваться в различном контексте. Кроме того, очень не хватает возможности поставить ссылку на другой документ (например, в процедуре выдачи рекламной кампании в расстановку сослаться на правила заполнения стадии "РК расставлена" в файле бизнес-процесса, или на стандарт уведомления о выполненном задании). Опять же, я знаю о возможности ссылаться на документы из документов Word и Excel, однако это настолько не удобно и криво в данном случае, что даже связываться не хочется.

При этом, потребность хранить кампании в папках контрагентов, в папках хронологических, в папках отраслевых и в папках тематических никуда не пропала.

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

...

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

 

Те модельные ситуации, которые Вы описали у нас, конечно же, есть. Но прежде чем заводить базу данных, мы обкатываем эти ситуации на таблицах в Excel\'e - разные таблицы, со своими полями и автофильтрами под разные контексты. База Контрагентов у нас хранится в 1С:CRM, но обрабатывается и анализируется посредством Excel (отбор и сортировка, "вывести список" - и вперед). Разумеется, я предвижу в будущем переход на какую-то более вменяемую систему хранения данных по Контрагентам, но для этого мне как раз и нужно понять, ЧТО именно я хочу от этой системы. Поэтому Excel таблицы, журналы и отчеты - это самое простое, быстро и легко модернизируемое на данный момент.

P.S. Частность:  Допустим Вы бы решили сохранить это мое сообщение в своей корпоративной базе знаний, которая построена в модели "папки-файлы".

  1. Как бы Вы его назвали?
  2. В какую бы папку Вы его положили?
  3. Как бы Вы его ассоциировали с упомянутыми выше документами?
  4. Если бы кто-то захотел прочитать и сообщение, и документы, на которые есть ссылка, сколько действий ему надо было бы совершить, чтобы все собрать?

Для этого сейчас у меня есть табличка, где хранятся ссылки на те материалы, которые представляют интерес (= должны быть помещены в базу знаний). В табличке есть поле, где проставлены теги, по которым можно искать материал, Вашему сообщению я присвоила бы теги "База знаний" и "Тех.Отдел". В поле "Источник" я указала бы "Форум ТРИЗ. Андрей Жуков". Кроме прочего я заполнила бы поле, где указан срок, когда следует вернуться к данному материалу, для Вашего сообщения я указала бы начало 2010 года (в рамках пересмотра бизнес-процессов компании и перевода проектов из "возможных" в "текущие"). В этой же табличке есть поле "Комментарий" - там я бы кратко указала суть сообщения и выделила заинтересовавшие меня моменты. Связь сообщения с документами - это тоже отдельное поле. Искать сообщение удобно либо по контексту (тегу) либо по источнику. И оно попалось бы мне на глаза в списке материалов, которые я изучала бы в январе следующего года, а если на тот момент реструктуризация сервера была бы для нас актуальной и оправданной по затратам задачей, мы бы сформировали текущий проект.

Но именно потому, что использование подобной таблички не настолько удобно, как использование Web-технологии, я и перевожу базу знаний на Web-интерфейс.

С уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]
2009-07-22 06:54:01
Катерина Аврутина » Андрей Жуков

Уважаемый Андрей!

За темой о воспитании детей я на некоторое время забросила эту свою ветку. А хотелось бы обсудить еще и следующие моменты:

Здесь Вы совершенно справедливо описываете Михаилу Опанасенко реальность. Но ведь эту задачу можно решить, ограничив доступ к Википедии "Фирма" для тех участников, которые не несут практической пользы для развития ресурса, а лишь паразитирую на нем. Иначе говоря, можно сделать:

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

Иначе как Вы представляете решение Вашей задачи "Я подумал, что надо жить иначе: небольшую часть - да - делать самим и качественно. А потом меняться и покупать готовое"? А может быть Вы ее уже успешно решили?

И еще: не могли бы Вы поделиться пошаговым алгоритмом внедрения "пустой ANY" для устранения системы хранения "файлы-папки" у Вас в компании. Как это происходило, сколько времени заняло и какие человеческие ресурсы потребовались?

Чем больше я об этом думаю, тем больше мне нравится эта идея. Хотелось бы представлять себе полную картину внедрения. А потом еще надо придумать, как сделать авторам "ANY-TRADE" предложение, от которого они не смогут отказаться :)

С уважением,

P.S. очень жаль, что эта тема не обсуждается так же активно, как и тема о воспитании. Я рассчитывала получить больший отклик на этом Форуме - ведь если не здесь, то где же?

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-22 20:01:29
Андрей Жуков » Катерина Аврутина

Добрый день!

Если я верно понял, схема такая:

1. В тихом месте (не индексируемым поисковиками) выкладывается Web-проект масштаба, например, как "ANY-TRADE".

2. Некоторому количеству приличных и умных людей рассылаются приглашения делать взносы (как Вы их описали) в обмен на доступ.

3. Авторы проекта, предположительно, сократят свои усилия по разработке - т.к. люди по п.1. держат и слово, и планку. Доход от реализации получат тоже.

4. Коллеги по п.1. бесплатно получат то, что иначе получили бы за деньги.

5. ...... ? ...........

N. Вдобавок можно было бы наладить функцию обмена данными и структурированными проектами.

N+1. Таким образом, получилась бы "интеллектуальная сеть"

Так? Уточните/поправьте?

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

Про внедрение напишу чуть позже [ но не зажилю :-) ]

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-23 14:35:20
Катерина Аврутина (Дробот) » Андрей Жуков

Добрый день!

1. В тихом месте (не индексируемым поисковиками) выкладывается Web-проект масштаба, например, как "ANY-TRADE".

Это да.

2. Некоторому количеству приличных и умных людей рассылаются приглашения делать взносы (как Вы их описали) в обмен на доступ.

Привлечение Участников в проект я бы не ограничивали лишь персональными приглашениями - так мы ограничиваем число потенциальных разработчиков. Описание проекта и условия участия в нем можно выложить в открытом доступе. Также можно анонсировать проект в тех "местах", где люди столкнутся с необходимостью чего-то разработать. Например, при получении пакета ANY-TRADE сразу же возникает необходимость продумывать алгоритм внедрения и создавать кучу документации из раздела "Технологии / Документы". В этом месте можно анонсировать проект, где можно найти/купить/обменяться уже готовыми решениями по этому поводу.

3. Авторы проекта, предположительно, сократят свои усилия по разработке - т.к. люди по п.1. держат и слово, и планку. Доход от реализации получат тоже.

Да. Плюс, возможно, получат новые направления по разработкам (об этом ниже).

4. Коллеги по п.1. бесплатно получат то, что иначе получили бы за деньги.

Здесь я бы ввела ограничение - чтобы объем получаемого был сопоставим вкладу Участника. Мне очень понравилась система оценки разрабатываемых документов, которую мы обсуждали с Алевтиной Кавтревой и Ксенией Ткалич в рамках проекта "Мастерская заработных плат". Там документ предлагалось оценивать по критериям:

  • уровень документа (с точки зрения новизны процесса)
  • объем описываемого процесса / масштабность решаемой задачи
  • полнота и законченность
  • полезность
  • ясность и простота изложения
  • применимость в отсутствие Автора

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

N. Вдобавок можно было бы наладить функцию обмена данными и структурированными проектами.

N+1. Таким образом, получилась бы "интеллектуальная сеть"

Это да.

Так? Уточните/поправьте?

Вдобавок к WishList-ам Авторов можно было бы создать WishList-ы Участников - те проекты, которые они хотели разрабатывать. Так, например, меня в ближайшее время интересует процесс создания франшизы. Я еще не искала материалы по этому поводу, но подозреваю, что вряд ли я найду инструкцию "Как грамотно создать успешную франшизу" уровня "Выведение шаманства из бухгалтерии". И мне придется набивать свои шишки самостоятельно. Так вот я бы предпочла набивать их под чутким руководством уважаемых Авторов подобного ресурса, зная что мои наработки, возможно лягут впоследствии в некие авторские продукты.

Про внедрение напишу чуть позже [ но не зажилю :-) ]


Я была бы весьма благодарна. Мне не нужна подробная детализации - достаточно будет крупноблочного описания процесса и моментов, на которые следует обратить внимание.

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-25 18:11:01
Андрей Жуков » Катерина Аврутина (Дробот)

Добрый день!

И еще: не могли бы Вы поделиться пошаговым алгоритмом внедрения "пустой ANY" для устранения системы хранения "файлы-папки" у Вас в компании. Как это происходило, сколько времени заняло и какие человеческие ресурсы потребовались? Чем больше я об этом думаю, тем больше мне нравится эта идея. Хотелось бы представлять себе полную картину внедрения. А потом еще надо придумать, как сделать авторам "ANY-TRADE" предложение, от которого они не смогут отказаться :)

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

Я обратил внимание на то, что Коллеги, работающие в фирме "Сычев и К" (как основные консультанты: С.В. Сычев, А.Б. Кавтрева, Г.В. Владимирова, К.В Ткалич и др., так и разработчики второго уровня) делают итоговые документы, пользуясь программой, напоминающий данный Форум только с большей функциональностью (например, там строятся иерархии, легко делается отображение сообщения или темы в разных контекстах, а также меняется статус сообщения, например, зародившись, как "сообщение Форума", оно простым нажатием может превратиться в "статью", "новость", "описание товара" и т.д., и т.п.).

Мне пояснили, что любое методическое сообщение появляется, как сообщение Форума. Автор заводит Тему, и далее он пишет сообщения, вставляет ссылки- примеры, слева и справа на панелях заводит "деревья" для аналогов-ссылок или шагов будущего алгоритма. По корпоративной сети к этому делу есть доступ. Так что другие разработчики, отвечают, вычитывая/критикуя оставленные сообщения именно в тех ветках, где надо.  (Похоже, кстати, на то, как проходит удаленная стажировка по разработке рекламных кампаний).

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

Так оно и разрабатывается (буквально, на первом этапе на внутреннем Форуме) и у них там есть даже нормо-часы на это дело и баллы, о которых Вы написали выше.

И вот. Когда первая версия готова, и руководство дало добро, все это автоматически преобразутся во внутренний ... сайт методики, с которого идут поставки Клиентам. Т.к., Вы видели кейсы RI и RI-Employ, то Вы, конечно, обратили внимание на то, что они даже внешне похожи на Форум.

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

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

Я спросил: "Можно ли купить и сколько стоит, и какие мне-хорошему будут скидки?"

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

Они мне предлагали альтернативы: "Давайте разработаем Вам..." (разное предлагали). Я же уперся: "Не надо мне ничего разрабатывать. Дайте Ваше!"

Вот и получилось, что когда я (выше) писал "сделал на ANY", я имел в виду, что у меня, кроме "ANY-TRADE", есть "штуковина", позволяющая создавать документы, структурированные документы, совместно их редактировать и т.д. А потом (в один клик) отправлять их прямиком в разделы корпоративного сайта, с которого периодически происходит "производство эталонного архива" (ну, как "ANY-TRADE", только мое).

И теперь, когда мы ссылаемся, общаясь на Форуме, на эталонный документ, который находится уже в кейсе, и мы всегда твердо уверены в том, что он эталонный. И когда сотрудники обращаются за шаблоном, они идут на "ANY-архив" и создают там известной кнопкой новый экзепмляр, который и используют. Архив, таким образом, испортить нельзя.

Это вот то, что я купил.

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

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-07-26 14:12:51
Редакция » Всем

Уважаемые Коллеги!

Действительно, функционально (крупноблочно) сейчас описанное выше выглядит так:

1. "Фабрика" (где создаются методики и разработчики общаются друг с другом  - здесь кипит работа)

2. Сайты готовых продуктов (очередная готовая версия отображаеся с фабрики - здесь тихо)

3. Кейсы (специальная программа преобразует готовые решения по п.2. в "локальные версии" (чит.: в "программные продукты"))

Если убрать 1 и 3, дать доступ к п.2., то, в принципе, можно подключить внешних разработчиков. К п.2., кстати, мы владельцам "ANY-TRADE" доступ давали (два года с хвостиком). Не закипела там жизнь. Действительно, когда появлялось что-то новое, его просто "подбирали". Когда задавали вопросы нам, то "закрывали" их от других Пользователей. Появилось немало приватных зон общения, как бы, разделенных стенками... Потом мы перенесли поддержку Пользователей на этот Форум + в Скайп. Стало гораздо живее.

К п.1. давать доступ, предполагаем, бессмысленно.

Что касается внутрифирменных баз знаний, то хоть Андрей Жуков и не согласен (но он слишком "продвинутый"), мы думаем, что п.2 для внутрифирменного использования может оказаться вполне достаточно. Функциональность по п.п. 1 и 2 абсолютно одинаковая. Более того, физически это один продукт, где п.п. 1 и 2 разделены визуально.

Спасибо,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-08-03 22:44:24
Катерина Аврутина (Дробот) » Андрей Жуков

Добрый день, Андрей!

Благодарю Вас за столь развернутое пояснение.

Это вот то, что я купил.

На самом деле я где-то так себе это и представляла (заранее проведя аналогию с Форумом, оболочкой ANY-TRADE и кейсами).

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

Мой вопрос касательно внедрения относился скорее к этой части. Мне хотелось прояснить ситуацию в виде: 

  • ДО внедрения этой системы документы хранились на файл-сервере таким-то образом
  • В процессе внедрения (перевода документов с файл-сервера) сделано вот это
  • Теперь работа организована следующим образом

Для иллюстрации приведу краткий алгоритм внедрения у нас Форума заказов.

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


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

В процессе внедрения Форума мы:

- создали закрытые Форумы для постоянных Заказчиков - там менеджеры Заказчика сами размещают заявки согласно правилам. Разовые Заказчики по-прежнему отправляют заявку на почту, заявку принимает и размещает на Форуме Клиент-менеджер Заказчика.

- создали закрытый внутренний раздел Форума (внутрення кухня) - там размещается заявка Клиент-менеджером Заказчка после обработки (проверки по чек-листу, заведения рабочей папки заказа, создания бизнес-процесса по заказу и проставления параметров заказа в бизнес-процессе).

- некоторое время мы принимали заявки по старой схеме, параллельно внося их на Форум от лица менеджеров Заказчика;

- в процессе этого мы откорректировали шаблоны подачи заявок,

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

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

- в рамках тестового запуска в пошаговом режиме оформляли заказы вместе с менеджерами Заказчика. В особо тяжелых ситуациях - после уточнения параметров заказа Клиент-менеджер оформлял заявку сам и выкладывал ее на Форуме от своего имени в качестве примера как надо.

- откорректировали регламент работы по заказу, вывесили в правилах для Заказчиков. При не соблюдении правил подачи заявки Клиент-менеджер дает ссылку на регламент работы.

- прописали шаблоны и речевые модули для ответов на форуме по типовым ситуациям.


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

Не могли бы Вы рассказать мне о Вашем переходе на новую систему в таком виде?

И вот еще что: удобство организации хранения файлов с системе ANY в том, что касается текстовых документов, для меня очевидно. А как обстоят дела с созданием и хранением файлов с НЕтекстовой информацией (графической, видео, аудио)?

С уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-08-04 01:45:52
Катерина Аврутина (Дробот) » Редакция
Уважаемая Редакция!

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

Я правильно понимаю, что с Вашей точки зрения идея, описанная здесь - это утопия?

С уважением,
Ответить Сообщение для всех [Показать все ответы на это сообщение]
2009-08-04 18:14:25
Редакция » Катерина Аврутина (Дробот)
Уважаемая Катерина!

Я правильно понимаю, что с Вашей точки зрения идея, описанная здесь - это утопия?

Надо придумать что-то еще.

-----

Слово "утопия", скорее, мы бы употребили по отношению к "Wiki-номике" и т.п. бизнес-моделям.

Спасибо,
Ответить Сообщение для всех [Нет ответов на это сообщение]
2009-08-04 23:59:23
Вера Максова » Всем
SharePoint

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

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

Мне не совсем понятно, зачем без острой необходимости выносить в Интернет корпоративную информацию? Почему не держать её у себя на сервере?
Ответить Сообщение для всех [Нет ответов на это сообщение]
2009-08-06 11:17:57
Андрей Жуков » Катерина Аврутина (Дробот)

Добрый день!

  • ДО внедрения этой системы документы хранились на файл-сервере...

В папках, доступ к  которым был разграничен. Недостатки такого способа описаны выше.

  • В процессе внедрения (перевода документов с файл-сервера) сделано...

 Документы переведены:

- шаблоны - в html-формат и загружены в оболочку ANY с тем, чтобы конкретные документы создавались не на их основе и размножались, а также для получения версионности и возможности обсуждать документ в режиме Форума.

- проекты - в структурированные форматы ANY-кейсов. (Пример можно представить: владельцы кейсов RI и RI-Employ могут обмениваться своими "рекламными кампаниями" или "упражнениями" и т.д. Если загрузить такой чужой проект в кейс, то он "ляжет структурированно" - то есть, по всем нужным веточкам).  Мы сделали для хранения проектов свои "кейсы" и у нас "ветвистые проекты" тоже теперь хранятся так.

- обмен документами (в т.ч., с Клиентами) постепенно преобразуется в общение с ними на Форуме. Т.е., сокращается пересылка разных вложений, а, вместе с этим, опасность пересортицы/ошибок и сокращается необходимость хранения длинных "историй" с конкретными документами в базе.

  • Теперь работа организована следующим образом
См. выше +

- некоторое время мы принимали заявки по старой схеме, параллельно внося их на Форум от лица менеджеров Заказчика;

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

и перемещение веток из папки в папку на разных стадиях бизнес-процесса (так, на стадии создания сценария и записи ролика, ветка находится в разделе "Продакшн", на стадии расстановки в трансляцию - в разделе "Кампании в расстановку", на стадии трансляции рекламной кампании - в разделе "В трансляции", по окончанию трансляции ветка помещается в раздел "Архив" за соответствующий месяц).

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

Вот пример подобрал: понажимайте в этой Теме во втором сообщении от Редакции на ссылки.

Также и в бизнес-процессах: если с какой-то стадии данные "ушли", то просто снимается отображение там. То есть, нет никакого перемещения. Лежит всегда в одном месте. Называется одинаково. А вот контексты вокруг "него" меняются. Не документ переходит со стадии на стадию, а "стадии" вращаются вокруг документа. Это очень удобно.

А как обстоят дела с созданием и хранением файлов с НЕтекстовой информацией (графической, видео, аудио)?

Легко. Также хранятся в одном месте и отображаются где надо.

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2010-08-11 21:37:05
Катерина Аврутина (Дробот) » Андрей Жуков

Уважаемый Андрей!

Поднимаю эту тему фактически год спустя :)

Искала ее "Поиском", с удовольствием перечитала – посмотрела на это дело "свежим" взглядом (да… было же у меня время на такие длинные посты на Форуме…).

Обнаружила, что Ваш последний постинг остался без моего ответа (я выпала из сетевой жизни и потом потеряла нити по начатым темам). В любом случае благодарю Вас за содержательный ответы и за то, что не "зажилил" :)

За этот год Wiki мы так и не внедрили, как-то необоснованно трудоемко оказалось. Покрутили и бросили.

Сейчас тестирую OfferBook. Хорошо, что не внедрили Wiki :)

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2010-08-12 13:53:33
Андрей Жуков » Катерина Аврутина (Дробот)

Да, аккуратно через год :-).

Вопрос "на засыпку": уничтожит ли "Оффербук" файл-сервер?

А то вчера услышал такой диалог:

- А у меня в проводнике Windows порядок.

- Это значит: ты не живешь, а обслуживаешь проводник.

Или люди будут только по страничке создавать?

C Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2010-08-12 22:48:23
Катерина Аврутина (Дробот) » Андрей Жуков

Да, аккуратно через год :-)


Это случайно получилось :)


Вопрос "на засыпку": уничтожит ли "Оффербук" файл-сервер?

...

Или люди будут только по страничке создавать?


Вы меня спрашиваете?

Я не знаю. Просто при внесении проекта в Оффербук возникла идея о базе знаний. Я вытащила тему, перечитала. Теперь я ее думаю в фоновом режиме.


Что Вы имеете в виду под файл-сервером? Место обмена документами между сотрудниками?


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


C Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2010-08-13 09:13:38
Андрей Жуков » Катерина Аврутина (Дробот)

Добрый день!

Вы меня спрашиваете?

Всех спрашиваю.

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

И да, и нет. То есть, конечно, если бы "при общем и неконтролируемом доступе" порядок возрастал, мы бы нарушили второй закон термодинамики :-). Но там фокус в том, что для создания "беспорядка А" в "Оффербуке" надо затратить большие усилия, чем для создания такого же беспорядка "А" в проводнике Windows, а восстановление порядка через версионность происходит сразу.

А вот "создавать там порядок", кому как, а мне, в общем, несложно.

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

С Уважением,

Ответить Сообщение для всех [Показать все ответы на это сообщение]
2010-08-13 11:49:09
Катерина Аврутина (Дробот) » Андрей Жуков

Добрый день!


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


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

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


С Уважением,

Ответить Сообщение для всех [Нет ответов на это сообщение]


Яндекс.Метрика