Content Management System - что мы под этим понимаем?
 |
|
11/12/2002
Уважаемые со-форумники!
Я тут озадачилась вопросом :
"А что конкретно мы понимаем под термином Content Management System ?"
Этот вопрос возник у нас в компании в процессе обдумывания промо-акции по продвижению нашей собственной разработки в этой области. Мнений было много, но мы с удивлением обнаружили, что каждый понимает это по-своему.
Решила обратиться к вам, что вы думаете на этот счет.
Для себя я раздробила этот вопрос на подвопросы:
1)Есть ли твердый перечень того функционала, который должен входить в систему?
2)Должен ли быть управляемым дизайн системы или это привилегия разработчиков?
3)Web-интерфейс доступа или некий "клиент"? (напр. для нашей системы клиентом является Lotus Notes R5)
4)Как быть с кросс-платформенностью? (напр. у нас сервером обязательно должен быть Domino R5, а в случае если система целиком и полностью написана на Java, вопросы плаформы отпадают)
5)Какие могут быть критерии безопасности системы - извне и внутри?
6)Насколько глубоко следует итегрировать систему с прочими бизнес-процессами клиента?
7)Насколько глубоко следует интегрировать систему с другими приложениями клиента? (т.е. стоит ли овчинка выделки - иногда проще разработать заново, чем связывать разрозненные приложения)
8)Какие гарантии должен получить заказчик?
9)Что оптимальней - продавать систему целиком или только некое "ядро" с дополнительными модулями?
Надеюсь на интересное обсуждение!
Возможно перечень вопросов следует расширить?! Ваши предложения - ?
С уважением, Виктория.
Я тут озадачилась вопросом :
"А что конкретно мы понимаем под термином Content Management System ?"
Этот вопрос возник у нас в компании в процессе обдумывания промо-акции по продвижению нашей собственной разработки в этой области. Мнений было много, но мы с удивлением обнаружили, что каждый понимает это по-своему.
Решила обратиться к вам, что вы думаете на этот счет.
Для себя я раздробила этот вопрос на подвопросы:
1)Есть ли твердый перечень того функционала, который должен входить в систему?
2)Должен ли быть управляемым дизайн системы или это привилегия разработчиков?
3)Web-интерфейс доступа или некий "клиент"? (напр. для нашей системы клиентом является Lotus Notes R5)
4)Как быть с кросс-платформенностью? (напр. у нас сервером обязательно должен быть Domino R5, а в случае если система целиком и полностью написана на Java, вопросы плаформы отпадают)
5)Какие могут быть критерии безопасности системы - извне и внутри?
6)Насколько глубоко следует итегрировать систему с прочими бизнес-процессами клиента?
7)Насколько глубоко следует интегрировать систему с другими приложениями клиента? (т.е. стоит ли овчинка выделки - иногда проще разработать заново, чем связывать разрозненные приложения)
8)Какие гарантии должен получить заказчик?
9)Что оптимальней - продавать систему целиком или только некое "ядро" с дополнительными модулями?
Надеюсь на интересное обсуждение!
Возможно перечень вопросов следует расширить?! Ваши предложения - ?
С уважением, Виктория.
|
|
|
14/12/2002
Я занимаюсь разработкой интернет магазинов и мне тоже интересен вопрос про функционал программы управления интернет-магазином.
Я для себя вот как представляю
ответы на представленные вопросы:
1.Перечня нет. Чем больше тем лучше. Наращивая функции своего магазина, я расширяю круг потенциальных клиентов.
2.Дизай должен быть Уникальным, добиться этого через программу управления сложно.Дизайн должны делать профи.
3.Некий "клеент" или web? Укаждого метода есть свои достоинства и недостатки. Для удаленки удобнее web, для работы из оффиса "клиент"
4.Если программа-клиент управления работает через web, то задумыватся над кросплатформенностью нет необходимости, а сервер стоит выбирать по задачам и средствам. Под задачи задачи ЛЮБОГО интернет магазина достаточно и MySQL.
5. ----
6. ----
7. Интергация с другими приложениями клиента? А вы знаете с какими. Это может быть 1С, BEST , своя разработка вообщем что угодно.
Интегрировать за разумное время и цену практически не реально.
8. Почитайте лицензию от Microsoft ......!!! Более грамотного отмаза от каких бы то нибыло обязательств и гарантий я не видел. Так что это от вас зависит.
9. Кому вы собираетесь продавать, некое "ядро". Директору компании который не бум-бум в этом? Что он будет с ним делать? Программист который сможет довести ваше ядро до ума, вероятно и сам сможет написать что-то подобное. Вариант на мой взгляд - предлагать готоваое решение под ключ. Что я и делаю относительно интернет магазина.
Я для себя вот как представляю
ответы на представленные вопросы:
1.Перечня нет. Чем больше тем лучше. Наращивая функции своего магазина, я расширяю круг потенциальных клиентов.
2.Дизай должен быть Уникальным, добиться этого через программу управления сложно.Дизайн должны делать профи.
3.Некий "клеент" или web? Укаждого метода есть свои достоинства и недостатки. Для удаленки удобнее web, для работы из оффиса "клиент"
4.Если программа-клиент управления работает через web, то задумыватся над кросплатформенностью нет необходимости, а сервер стоит выбирать по задачам и средствам. Под задачи задачи ЛЮБОГО интернет магазина достаточно и MySQL.
5. ----
6. ----
7. Интергация с другими приложениями клиента? А вы знаете с какими. Это может быть 1С, BEST , своя разработка вообщем что угодно.
Интегрировать за разумное время и цену практически не реально.
8. Почитайте лицензию от Microsoft ......!!! Более грамотного отмаза от каких бы то нибыло обязательств и гарантий я не видел. Так что это от вас зависит.
9. Кому вы собираетесь продавать, некое "ядро". Директору компании который не бум-бум в этом? Что он будет с ним делать? Программист который сможет довести ваше ядро до ума, вероятно и сам сможет написать что-то подобное. Вариант на мой взгляд - предлагать готоваое решение под ключ. Что я и делаю относительно интернет магазина.
|
|
|
15/12/2002
shoponline, спасибо за ответ!
Интегрировать за разумное время и цену практически не реально. >> Ну здесь я бы поспорила ))) Есть опыт интеграции Инет-магазина(Ява/Оракл) с 1С:Склад - вполне реально. Тут ключевым являлется только цена)))
Почитайте лицензию от Microsoft ......!!! >> Читала, знаю, но тем не менее заказчики требуют включать определенные санкции в договора, хотелось бы понять насколько можно прогибаться, что гарантировать и т.д.
Кому вы собираетесь продавать, некое "ядро". >> Под ядром я подразумевала НЕ ДВИЖОК, а некий готовый модуль, например, интернет-магазин))), а к нему предлагать некие "бантики" типа "аукцион", "рассылка", "публикации" и т.д. Т.е. решение в любом случае будет под ключ, но в "обрезанном виде". Или интереснее все в одном? (естесственно, определенный уровень кастомизации под заказчика учитывается).
Интегрировать за разумное время и цену практически не реально. >> Ну здесь я бы поспорила ))) Есть опыт интеграции Инет-магазина(Ява/Оракл) с 1С:Склад - вполне реально. Тут ключевым являлется только цена)))
Почитайте лицензию от Microsoft ......!!! >> Читала, знаю, но тем не менее заказчики требуют включать определенные санкции в договора, хотелось бы понять насколько можно прогибаться, что гарантировать и т.д.
Кому вы собираетесь продавать, некое "ядро". >> Под ядром я подразумевала НЕ ДВИЖОК, а некий готовый модуль, например, интернет-магазин))), а к нему предлагать некие "бантики" типа "аукцион", "рассылка", "публикации" и т.д. Т.е. решение в любом случае будет под ключ, но в "обрезанном виде". Или интереснее все в одном? (естесственно, определенный уровень кастомизации под заказчика учитывается).
|
|
|
15/12/2002
Ну вот только с 1С интегрировать и можно ...:-)
Best - досовская программы вообще не пригоден к лювой интеграции, а самостоятельные разработки сложны в плане незнания их.
Если есть желание можно и прогнутся, конечно, но если программы у вас действительно стоящая, я бы несоветовал прогибатся сильно, можно пойти на определенные оговорки не более.
Если вы предлогаете готовое решение то его можно предлагать как базовый самодостаточный минимум, а навороты делать отдельно, это правильно.
Best - досовская программы вообще не пригоден к лювой интеграции, а самостоятельные разработки сложны в плане незнания их.
Если есть желание можно и прогнутся, конечно, но если программы у вас действительно стоящая, я бы несоветовал прогибатся сильно, можно пойти на определенные оговорки не более.
Если вы предлогаете готовое решение то его можно предлагать как базовый самодостаточный минимум, а навороты делать отдельно, это правильно.
|
|
|
16/12/2002
Добавлю по поводу совместимости.
Я бы поставил вопрос так: система должна поддерживать _стандартные_ и признанные форматы обмена данными. Например уметь гибко работать с XML.
Соответственно - если кастомная система заказчика умеет работать с тем же XML, то все будет хорошо. Если нет - то это уже претензия к разработчикам этой кастомной системы.
Я бы поставил вопрос так: система должна поддерживать _стандартные_ и признанные форматы обмена данными. Например уметь гибко работать с XML.
Соответственно - если кастомная система заказчика умеет работать с тем же XML, то все будет хорошо. Если нет - то это уже претензия к разработчикам этой кастомной системы.
|
|
|
17/12/2002
AntonM, спасибо за ответ!
Полностью с вами согласна.
К сожалению, проблемы чаще всего упираются не в собственную разработку, а в софт заказчика, который:
а) не обновлял версии с 9.. года
б) купил хрякнутый диск на Горбушке
с) получил программу бухучета от собственного сынульки, написавшего эту программу как зачет по информатике
С ними как дружить?! ;)
За себя могу сказать честно - если заказчик мало того, что попадает в вышеперечисленные категории, так еще и отличается завидным жлобством и твердолобостью, я с ним не работаю, т.к. давно убедилась, что трудозатраты в таком случае всегда оказываются выше полученной прибыли.
Полностью с вами согласна.
К сожалению, проблемы чаще всего упираются не в собственную разработку, а в софт заказчика, который:
а) не обновлял версии с 9.. года
б) купил хрякнутый диск на Горбушке
с) получил программу бухучета от собственного сынульки, написавшего эту программу как зачет по информатике
С ними как дружить?! ;)
За себя могу сказать честно - если заказчик мало того, что попадает в вышеперечисленные категории, так еще и отличается завидным жлобством и твердолобостью, я с ним не работаю, т.к. давно убедилась, что трудозатраты в таком случае всегда оказываются выше полученной прибыли.
|
|
|
17/12/2002
2 Виктория
По поводу "дружбы":
Я таки не пытаюсь с ними "дружить", т.к. это тупиковый путь развития. Естественно разок-другой объясню заказчику весь спектр проблем продолжения работы с необновляемым, неподдерживаемым и т.п. ПО.
Те, кто понял, в чем суть этих "граблей" - сами стремятся к переходу на нормальные, стандартизированные "рельсы". А если люди не понимают, что из-за вполне вероятного глюка на_колене_сделанной программы они могут потерять намного больше чем стоит лицензированное ПО..., то зачем мне их проблемы!? :-)
По поводу "что такое CMS", какова функциональность, интерфейс и т.п. у меня такое видение:
CMS - это общее название целого ряда ПО. Ну как "Графический редактор"... которыми являются и Photoshop c лицензией ~$800 и поставляемый с виндами Paint... Функциональность, стоимость и назначение у них разное. То же самое и с CMS, основной признак которых позволять управлять содержанием. Как управлять, насколько удобно, насколько полно и т.п. это уже вопрос конкретной реализации.
Почему, например, мы имеем собственную разработку CMS? Потому что наши заказчики в своей массе не готовы платить за разработки на основе нормальных, призананных систем. Когда принималось решение о собственной разработке лицензия того же Оракл-портала (и подобных вещей) стоила ой-е-ей :-) каких денег. Думаю, моя мысль понятна...
О требованиях к CMS. По мне так все сказано в русском переводе СМS - она должна управлять контентом. При этом не надо путать с конструкторами сайтов. Т.е. для CMS должно быть пофиг что на ней будут делать - сайт визитку, портал, магазин, внутреннюю систему управления бизнесом и пр. А как только всплывают слова "модуль новостной ленты", "модуль интернет магазина" - все, это конструктор сайтов. И еще важный пункт. CMS должна работать со стандартами (какими это отдельный вопрос). Т.е. импорт-экспорт данных с помощью стандартных форматов. Ведение разработок на основе CMS должно вестись "стандартными" специалистами. Т.е. термина типа "програмист 1C" не должно появляться.
О интерфейсе. Чем удобнее, гибче и т.п. тем лучше :-) Может быть веб-интерфейс, может быть "клиент", может быть и то и то....
По поводу "дружбы":
Я таки не пытаюсь с ними "дружить", т.к. это тупиковый путь развития. Естественно разок-другой объясню заказчику весь спектр проблем продолжения работы с необновляемым, неподдерживаемым и т.п. ПО.
Те, кто понял, в чем суть этих "граблей" - сами стремятся к переходу на нормальные, стандартизированные "рельсы". А если люди не понимают, что из-за вполне вероятного глюка на_колене_сделанной программы они могут потерять намного больше чем стоит лицензированное ПО..., то зачем мне их проблемы!? :-)
По поводу "что такое CMS", какова функциональность, интерфейс и т.п. у меня такое видение:
CMS - это общее название целого ряда ПО. Ну как "Графический редактор"... которыми являются и Photoshop c лицензией ~$800 и поставляемый с виндами Paint... Функциональность, стоимость и назначение у них разное. То же самое и с CMS, основной признак которых позволять управлять содержанием. Как управлять, насколько удобно, насколько полно и т.п. это уже вопрос конкретной реализации.
Почему, например, мы имеем собственную разработку CMS? Потому что наши заказчики в своей массе не готовы платить за разработки на основе нормальных, призананных систем. Когда принималось решение о собственной разработке лицензия того же Оракл-портала (и подобных вещей) стоила ой-е-ей :-) каких денег. Думаю, моя мысль понятна...
О требованиях к CMS. По мне так все сказано в русском переводе СМS - она должна управлять контентом. При этом не надо путать с конструкторами сайтов. Т.е. для CMS должно быть пофиг что на ней будут делать - сайт визитку, портал, магазин, внутреннюю систему управления бизнесом и пр. А как только всплывают слова "модуль новостной ленты", "модуль интернет магазина" - все, это конструктор сайтов. И еще важный пункт. CMS должна работать со стандартами (какими это отдельный вопрос). Т.е. импорт-экспорт данных с помощью стандартных форматов. Ведение разработок на основе CMS должно вестись "стандартными" специалистами. Т.е. термина типа "програмист 1C" не должно появляться.
О интерфейсе. Чем удобнее, гибче и т.п. тем лучше :-) Может быть веб-интерфейс, может быть "клиент", может быть и то и то....
|
|
|
20/12/2002
Расширяю предложения.
А посмотреть то можно, где Ваш CMS, о чем вообще разгоор идет.
Что продаете то?
И как насчет Виктории, она прилагается к CMS или нет?
Дадим 500 баксов за умный ответ.
А посмотреть то можно, где Ваш CMS, о чем вообще разгоор идет.
Что продаете то?
И как насчет Виктории, она прилагается к CMS или нет?
Дадим 500 баксов за умный ответ.
|
|
|
23/12/2002
AntonM!
Спасибо большое за ответ!
Была в командировке, поэтому такая задержка ))
В общем и целом согласна, единственное, не совсем поняла по поводу контруктора и менеджера.
Мне кажется, это принципиально разные вещи.
Во втором случае это идеология CMS, а в первом - его практическая реализация.
Понятно, что сам "движок" в утрированном варианте действует для любого модуля одинаково "получил - опубликовал - вернул на редакцию - опубликовал - удалил" (это я сильно грубо;)), но тем у каждого модуля свой формат (если так понятнее, свой XML), что требует определенной кастомизации, и вопрос заключался в том, нужно ли продавать клиенту в рамках своего CMS дополнительные функции, которые ему, пока(фактор "пока" тоже вопрос%)) не нужны?
Возможно, немного запутанно, но надеюсь, поймете.
Еще раз спасибо за интересный ответ!
Спасибо большое за ответ!
Была в командировке, поэтому такая задержка ))
В общем и целом согласна, единственное, не совсем поняла по поводу контруктора и менеджера.
Мне кажется, это принципиально разные вещи.
Во втором случае это идеология CMS, а в первом - его практическая реализация.
Понятно, что сам "движок" в утрированном варианте действует для любого модуля одинаково "получил - опубликовал - вернул на редакцию - опубликовал - удалил" (это я сильно грубо;)), но тем у каждого модуля свой формат (если так понятнее, свой XML), что требует определенной кастомизации, и вопрос заключался в том, нужно ли продавать клиенту в рамках своего CMS дополнительные функции, которые ему, пока(фактор "пока" тоже вопрос%)) не нужны?
Возможно, немного запутанно, но надеюсь, поймете.
Еще раз спасибо за интересный ответ!
|
|
|
23/12/2002
Green!
Конкретно здесь, я ничего не продаю. В рамках этой темы, мне были бы больше интересны не клиенты, а мнения людей с практическим опытом по разработке и внедрению CMS, но судя по активности таких здесь мало ((
Ответ на второй вопрос:
Виктория прилагается к CMS на этапе кастомизации, внедрения и пилотной эксплуатации в качестве разработчика.
В любом случае, 500 баксов оставьте себе. Рекомендую применить их на общеинтеллектуальное развитие и более презентабельный домен.
Конкретно здесь, я ничего не продаю. В рамках этой темы, мне были бы больше интересны не клиенты, а мнения людей с практическим опытом по разработке и внедрению CMS, но судя по активности таких здесь мало ((
Ответ на второй вопрос:
Виктория прилагается к CMS на этапе кастомизации, внедрения и пилотной эксплуатации в качестве разработчика.
В любом случае, 500 баксов оставьте себе. Рекомендую применить их на общеинтеллектуальное развитие и более презентабельный домен.
Форум закрыт. Написание сообщений ограничено
