这些表达，沟通案例，都是特定环境下的投入最小化，价值最大化，代表个人意见，仅供参考
在信息化治理中，“信息烟囱”“数据孤岛”常被用以喻指同一个大组织下，各部门信息化自搞一套、自成体系，壁垒森严，信息无法实现互联、共享、交换利用；
高绩效甲方组织在信息化建设进程中，联合提供信息化建设服务的乙方一起，总是免不了建孤岛，搭烟囱，处处钟乳石，然后，打通孤岛，连接烟囱，消灭钟乳石，如此往复；在这个过程中，信息化治理，数据前台、中台、后台等，被频繁提及，“统一”忙得很，忙着统一组织、消息、待办、入口、平台……
那么，建个统一门户吧，提供统一、规范的接口，对甲方各类服务和应用进行集成展示，实现跨数据，跨应用，跨平台的接入，为甲方用户提供统一的个性化综合信息门户；
可是，在最终交付项目的时候，总会遇到甲方说，你这个门户不好看，你能不能给我看看其他案例；我们的要求是：现代感、设计感、开放性，眼前一亮；
甲方对于门户美的追求，是高级、高价值的需求，而在乙方的常规销售过程及交付过程中，把门户的美当作附加的，捎带的；双方认知的巨大误差，造成在门户的交付上，总会给乙方带来投入与产出的巨大落差，同时总难以让甲方满意；
避免这种情况产生的最好办法，当然是商务沟通先行，需求前置，乙方高投入实现门户的高级需求，并能从甲方获取高产出；这就要求，甲乙双方，在门户的销售与交付过程中，基于门户能力、内容、美观三要素，要保持两个统一的概念：门户配置和门户设计；
选择门户配置，在产品门户能力的基础上，侧重于门户内容及价值；
选择门户设计，门户内容，门户价值，门户美观，三者兼具；
如若不然呢，选择门户配置，要有门户美的设计，再遇到前面表述的，甲方说，你这门户不美呢，那就只能是交付过程中沟通了，做乙方的，就只能期待……
咱们先来看一个小案例，看看门户美不美的概念该如何定义，能不能有个什么标准，也将决定甲乙双方有必要基于什么样的标准进行沟通；
这是一个项目上，甲乙双方在门户“千人千面”“门户不够美”的交付上正纠结着，甲方项目负责人，看到这个页面，说了句：“你看，你这个就挺好，怎么不给我们做一个呢”；
就那么瞬间，就顿悟了，这个门户页面到底美不美的不说，但这个项目门户的交付，再也不能在“美不美”这个点上，纠缠不清了；这门户的“千人千面”，得看你怎么理解怎么沟通了，如果项目的甲乙双方都认为门户要美得千姿百态，那死定了；而是尽量从权限体系，组织架构体系，自然而然形成门户内容的千人千面；
那么，接下来，甲乙双方针对门户交付，就得平衡配置与设计，平衡投入与产出；都需要有共同的风险认知、统一的推进思路；
实际双方沟通汇报，推动项目进程时，还要有精准的切入点，有一些切实可行的动作，比如：
1、找准主色调：恰恰是对美有较为精致要求的甲方，通常都会有公司CI（企业形象识别系统）规范文件，或者甲方官方网站，都可以找到主题色，确定门户空间的主体色彩基调，一百年不动摇；
2、强化内容设计：从这个门户美不美的思考中，转移到这个门户需不需要；
3、传递门户能力：编制门户配置操作手册，培训传递门户配置能力；展示具备规范接口，集成开发的能力；
不妨针对常规门户的交付做一个小小的总结：
美，因人而异；但价值可以统一；甲乙双方都需要从项目组、主管领导、决策领导，传递门户价值，交付门户价值；
有案例有模板，前端可视化配置，会有培训，有配置方法的传递；授人以鱼不如授人以渔，用户自己可以负责美
外在的美感，还需要内容支撑，这需要时间，需要有内容的积累与沉淀；美在形式，内容是核，特别是项目初期，纠结美，连核都没有；
写这些内容，做这些表达（一定不是全部），最终是希望，甲乙双方，不光是门户的交付，是所有的项目交付上，能在沟通的维度上达成一致，然后一起去实现投入最小化，价值最大化。
小案例：从功能描述，到业务场景，再到价值沟通，上升到文化建设
项目实施沟通案例：我不是来画表单的，我是来根据管理需要设计业务的；尝试从业务场景描述到价值沟通
项目实施沟通案例：不能完全解决客户管理痛点，尝试触达客户痒点，基于企业文化建设的内涵与客户进行沟通
项目实施沟通案例：存为草稿和暂存待办，尝试基于业务场景说服客户不要去掉“存为草稿”
