操作型BI解决排队等待的方案
innovate511
务商都是垄断企业，他们暂时没解决方案的迫切性，但迟早需要提高服务。
另据新闻说英国人每天也会有大量时间浪费在排队上，所以排队浪费时间是世界所有城市人的问题，并非中国。
排队的操作型BI解决方案的效果应该是：首先是预定，然后是智能提示你大概什么时候去，最后1小时或半小时再友情提示精确信息。人性化服务还可以包括最
近办理地点提示、前面还有多少人，按照前一天、前一周的经验判断，大概还有多少时间供以参考。当然需要提供用户提前取消、推迟排队的服务。
解决方案的效果：服务商最大限度地提供精确性服务，提高竞争力；用户最大限度利用自己有限的时间，将排队的时间用以其他方面的事情，或者休息、陪家
人。
行业应用：银行、医院、电信、某些政府机构等。
现状：目前上海3级医院已经开始采用预定挂号制，不过服务还不够精确；银行和电信有排队机，不用站着排队，不过还是需要坐在银行等待半小时到1小时以上
时间。
业务流程方案：首先通过网站、电话预订，电脑将根据你的办理时间要求、地址和现有排队状况，让你确定在哪个办理点和时间范围办理，通知你前面有多少人排
队，预估大约什么时候轮到你。
正常情况下，当你按时去办理的时候，根据预计你的路程（如需要半小时），可以提前发短信通知（可为估计路程2倍的时间提醒，如1小时），你前面还有20
人，根据昨天经验，预计1小时候后轮到你，根据一周前的经验，预计55分钟轮到你，请提前出发办理。如果有急事，需要取消或推迟，可电话、网络办理，而
推迟的话，可以根据实际情况往后推延，如果短信提示后5分钟后再推迟预约，将视作取消，需重新预约或去随机办理柜台排队办理。
预计时间的规则，可以分别按照前一天或前一周、前一月的平均某种业务的办理时间来计算每个预定业务的时间，然后统计在一起后告诉用户，给予参考。由于具
体办理业务的时间会有误差，所以事前再提前短信通知非常有必要。
操作方式：由于用户种类繁多，不可能所有用户都做预定业务，所以需要分预定业务和随机办理业务两种柜台，随机办理的人员觉得不爽，也可以加入预定的行
列。业务人员每处理完一个业务，操作性BI需要自动计算最新状况，以便自动短信通知。
当然国内3级医院几乎处于垄断地位，无论医院服务好不好，老百姓都会挤破头去，如果以后中高级医院竞争在国内大城市加大，这样的智能化预定系统才能有其
存在的意义。而且医院的紧迫事务较多，无法提前预测并提前预约，更多是电脑先帮你排队，如果人太多，还是要等候一点时间。
其初衷就是现在人的时间宝贵，没太多时间浪费在排队上，人们需要更多时间休息和做别的事情，而要维持社会文明的秩序，排队还是有必要的，那么就让电脑来
帮你排队吧。操作型BI，其实也是一种业务系统，只是在业务系统中增加了一些BI思想和计算方法，但有时非常有实际意义，可以改变企业对BI的传统开
发，BI不仅仅是事后分析、查询、绩效考核、预测，还可以帮助业务系统吸收BI的精髓。
即兴发挥的方案，不知道可行度有多高，但相信就像IBM的广告一样，我们的目标是，让地球充满智慧。
syfins
原来这就是操作型BI啊
syfins
发，BI不仅仅是事后分析、查询、绩效考核、预测，还可以帮助业务系统吸收BI的精髓。
没有必要把这个上升到系统的高度吧
也就是BI输出了一条业务规则
由营业系统将这个业务规则实现而已
这个东西也就是当前没有业务需求而已
对于运营商和银行，对这部分都不care
因为营业场所的固定成本开销很大，如果服务更好，更多的人来了，还要继续新建服务厅和分行
现有的策略是大力发展电子渠道，电子渠道一年的所有支出搞不好都没一个服务厅的开销大
On 8月22日, 下午2时49分, innovate511 <innovate...@gmail.com> wrote:
lanxing2210
clouds.lau
innovate511
定义为操作性BI的应用，不管这个术语使用是否准确，但我表达出了我的意思。
正因为是应用预测，所以实际使用时需要提醒“根据以往经验，估计。。。”，也就是说仅仅是参考，帮助用户判断。而且我设想的应用中，应该有个提前提醒，
比如他预定的时候前面有100人排队，那么当前面10-20人排队的时候提醒，准确性会大很多，用户稍微提前点出发，等一小会就OK。
至于现在没有这种应用，有很多原因，包括西方发达国家也有大量排队事件嘛。就像油价足够高，才能推动新能源的发展一样，BI的更多应用，需要实际需求越
来越迫切，只是一个时间问题。
On 8月23日, 下午3时08分, "clouds.lau" <clouds....@gmail.com> wrote:
> 还需要考虑BI结果的准确性，以及由于预测失败带来的后果。 因为是你主动推送给用户的，你需要承担一定的责任。
Q
说实话，我做了9年BI，没做过定位为“操作性BI”的项目，只是我想到这个这个业务应用不是普通业务系统思维能做的，需要有BI的思想和技术，所以我定义为操作性BI的应用，不管这个术语使用是否准确，但我表达出了我的意思。
正因为是应用预测，所以实际使用时需要提醒“根据以往经验，估计。。。”，也就是说仅仅是参考，帮助用户判断。而且我设想的应用中，应该有个提前提醒，比如他预定的时候前面有100人排队，那么当前面10-20人排队的时候提醒，准确性会大很多，用户稍微提前点出发，等一小会就OK。
至于现在没有这种应用，有很多原因，包括西方发达国家也有大量排队事件嘛。就像油价足够高，才能推动新能源的发展一样，BI的更多应用，需要实际需求越来越迫切，只是一个时间问题。
Rex
interstage
对你的电子化“排队系统”本身，提供一下个人建议，因为，刚刚前几天在吃饭的时候和别人胡侃过这个系统的业务设计模型如下：
1，你的“排队系统”是为打破现场排队现场享受服务的模式，因此属于“非见面交易却要现场享受服务或商品的业务”，这正是我目前从事的行业，目前的对于
这类业务由4个核心组成，第一个核心是接入系统，按照你设计的接入方式为“网站和电话预订”，这个在设计上是常见的，当然目前还可能增加短信预订，
WAP预订，社区附近的便利店或物业门卫等老百姓便利场所的客户端预订，这个接入方式本身无问题，问题在于，这些接入方式的广而告之和公信力选择上，如
果是商业行为，建一个网站和开设一个IVR的电话，这个让用户聚齐并形成规模性是需要商务，市场，营销等各方面配合和努力，技术实现层面在这个层面上没
什么价值，比如你自己申请了一个电话叫40012345678专门做这个“排队系统”的IVR接入，你的竞争对手和电信的118114合作，来做这
个“排队系统”的IVR接入，不管你的系统在以后3点上或BI设计排队算法模型做的再优秀，你的竞争对手只要后面的系统不要太差或者基本能用，你这个项
目就落后了。
2，第2个核心是门户本身，你BI设计排队算法是否优秀目前不重要，重要的是国内3级医院的排队系统是否愿意和你的门户系统对接，这绝对不是一个技术层
面能解决的问题，涉及到一系列商务的问题。
3，第3个核心是支付问题，既然是“非见面交易却要现场享受服务的”排队系统，非见面交易如何解决，你千万别告诉我接一个”支付宝“就可以，交易有远程
交易和现场交易等，你的系统选择哪些交易平台，他们是否愿意，这些交易系统是否符合当地大众的特色等等，这也不是技术层面的问题。
4，由于“非见面交易却要现场享受服务”的业务，目前最大的问题是缺少凭证环节，这个凭证在”现场交易现场享受业务“中不是大问题，比如收据，发票，门
诊挂号券，这些都可以在现场得到，但电子化的“非见面交易却要现场享受服务”的业务，电子凭证确实大问题了，采用什么方式做电子凭证，如何传递，如何通
过公信力的方式让用户得到，因此，这个也不是技术层面能解决的。
等你把你的“排队系统”从以上4点涉及到业务和资源等商务情况想透了并确认可以实施，再考虑技术上如何用BI却优化吧，再总结出你所说的”操作性
BI“。在没有想明白这些非技术的业务层面，请慎用”技术“来指导”业务“，更要慎用”BI思想和计算方法“来指导”业务“，呵呵，以上意见仅仅为个人
意见，请别拍砖。
Q
且不说，你的这个业务设计和方案是不是可以定义为“操作性BI”这个范围，如果展开这个定义，你我又开始一场争论了，呵呵，所以不做讨论了。
对你的电子化“排队系统”本身，提供一下个人建议，因为，刚刚前几天在吃饭的时候和别人胡侃过这个系统的业务设计模型如下：
1，你的“排队系统”是为打破现场排队现场享受服务的模式，因此属于“非见面交易却要现场享受服务或商品的业务”，这正是我目前从事的行业，目前的对于这类业务由4个核心组成，第一个核心是接入系统，按照你设计的接入方式为“网站和电话预订”，这个在设计上是常见的，当然目前还可能增加短信预订，WAP预订，社区附近的便利店或物业门卫等老百姓便利场所的客户端预订，这个接入方式本身无问题，问题在于，这些接入方式的广而告之和公信力选择上，如果是商业行为，建一个网站和开设一个IVR的电话，这个让用户聚齐并形成规模性是需要商务，市场，营销等各方面配合和努力，技术实现层面在这个层面上没什么价值，比如你自己申请了一个电话叫40012345678专门做这个“排队系统”的IVR接入，你的竞争对手和电信的118114合作，来做这个“排队系统”的IVR接入，不管你的系统在以后3点上或BI设计排队算法模型做的再优秀，你的竞争对手只要后面的系统不要太差或者基本能用，你这个项目就落后了。
2，第2个核心是门户本身，你BI设计排队算法是否优秀目前不重要，重要的是国内3级医院的排队系统是否愿意和你的门户系统对接，这绝对不是一个技术层面能解决的问题，涉及到一系列商务的问题。
3，第3个核心是支付问题，既然是“非见面交易却要现场享受服务的”排队系统，非见面交易如何解决，你千万别告诉我接一个”支付宝“就可以，交易有远程交易和现场交易等，你的系统选择哪些交易平台，他们是否愿意，这些交易系统是否符合当地大众的特色等等，这也不是技术层面的问题。
4，由于“非见面交易却要现场享受服务”的业务，目前最大的问题是缺少凭证环节，这个凭证在”现场交易现场享受业务“中不是大问题，比如收据，发票，门诊挂号券，这些都可以在现场得到，但电子化的“非见面交易却要现场享受服务”的业务，电子凭证确实大问题了，采用什么方式做电子凭证，如何传递，如何通过公信力的方式让用户得到，因此，这个也不是技术层面能解决的。
等你把你的“排队系统”从以上4点涉及到业务和资源等商务情况想透了并确认可以实施，再考虑技术上如何用BI却优化吧，再总结出你所说的”操作性BI“。在没有想明白这些非技术的业务层面，请慎用”技术“来指导”业务“，更要慎用”BI思想和计算方法“来指导”业务“，呵呵，以上意见仅仅为个人意见，请别拍砖。
...
interstage
人减少排队等候的时间，不是医院所考虑的。让医院做远程排队的前提是他的门诊资源不饱和，让病人多来占这些资源。因此医院单独来做，不符合市场和商务规
则。但对政府和商业企业做排队系统意义就不一样，政府来做医院排队系统，意义在于优化区域内的医院门诊资源和减少老百姓的排队时间，属于民生工程；商业
企业做排队系统意义在于，商业企业可以通过市场化手段先批发出区域内的医院门诊资源，再以零售方式卖给老百姓，同时在其他资源上获取商业资源，属于市场
行为。
所以，Q，你这个假设某一家医院先上这样的系统，我问过很多医院的相关人员，他们一致表态，不符合市场行为，这个业务模式反而不可拓展。
On 8月24日, 下午1时37分, Q <happys...@gmail.com> wrote:
> 这个场景并不需要考虑这么复杂吧！
> 可以假想这样一家医院，设一个预定挂号电话，一个接线员（或者就是IVR吧），一台电脑，上面运行排队系统，病人打电话挂号，接线员输入病人信息，反馈给病人一 个排队号，并给出到达医院时间点的建议。
>
> 关于这个业务模式，并不是什么新的东西。而且不管怎样，需要减少排队等候的时间，这个需求是确确实实存在的，通过一种创新的业务流程来满足需求，可以。或者通过 BI来帮助现有的业务模式优化，也可以满足。
>
> 关于排队的话题，07年有个帖子可以参考一下：http://groups.google.com/group/ttnn/browse_thread/thread/19a98b9381c8...
>
> 2009/8/24 interstage <buer0...@gmail.com>
>
>
>
> > 且不说，你的这个业务设计和方案是不是可以定义为“操作性BI”这个范围，如果展开这个定义，你我又开始一场争论了，呵呵，所以不做讨论了。
>
> > 对你的电子化“排队系统”本身，提供一下个人建议，因为，刚刚前几天在吃饭的时候和别人胡侃过这个系统的业务设计模型如下：
>
> > 1，你的“排队系统”是为打破现场排队现场享受服务的模式，因此属于“非见面交易却要现场享受服务或商品的业务”，这正是我目前从事的行业，目前的对于这类业务 由4个核心组成，第一个核心是接入系统，按照你设计的接入方式为“网站和电话预订”，这个在设计上是常见的，当然目前还可能增加短信预订，WAP预订，社区附近 的便利店或物业门卫等老百姓便利场所的客户端预订，这个接入方式本身无问题，问题在于，这些接入方式的广而告之和公信力选择上，如果是商业行为，建一个网站和开 设一个IVR的电话，这个让用户聚齐并形成规模性是需要商务，市场，营销等各方面配合和努力，技术实现层面在这个层面上没什么价值，比如你自己申请了一个电话叫 40012345678专门做这个“排队系统”的IVR接入，你的竞争对手和电信的118114合作，来做这个“排队系统”的IVR接入，不管你的系统在以后3 点上或BI设计排队算法模型做的再优秀，你的竞争对手只要后面的系统不要太差或者基本能用，你这个项目就落后了。
>
> > 2，第2个核心是门户本身，你BI设计排队算法是否优秀目前不重要，重要的是国内3级医院的排队系统是否愿意和你的门户系统对接，这绝对不是一个技术层面能解决 的问题，涉及到一系列商务的问题。
>
> > 3，第3个核心是支付问题，既然是“非见面交易却要现场享受服务的”排队系统，非见面交易如何解决，你千万别告诉我接一个”支付宝“就可以，交易有远程交易和现 场交易等，你的系统选择哪些交易平台，他们是否愿意，这些交易系统是否符合当地大众的特色等等，这也不是技术层面的问题。
>
> > 4，由于“非见面交易却要现场享受服务”的业务，目前最大的问题是缺少凭证环节，这个凭证在”现场交易现场享受业务“中不是大问题，比如收据，发票，门诊挂号券 ，这些都可以在现场得到，但电子化的“非见面交易却要现场享受服务”的业务，电子凭证确实大问题了，采用什么方式做电子凭证，如何传递，如何通过公信力的方式让 用户得到，因此，这个也不是技术层面能解决的。
>
> > 等你把你的“排队系统”从以上4点涉及到业务和资源等商务情况想透了并确认可以实施，再考虑技术上如何用BI却优化吧，再总结出你所说的”操作性BI“。在没有 想明白这些非技术的业务层面，请慎用”技术“来指导”业务“，更要慎用”BI思想和计算方法“来指导”业务“，呵呵，以上意见仅仅为个人意见，请别拍砖。
>
> > ...
Q
谷歌拼音
> > 即兴发挥的方案，不知道可行度有多高，但相信就像IBM的广告一样，我们的目标是，让地球充满智慧。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
interstage
越多越好，而是更希望病人固定在一定范围。但中国的老百姓很奇怪，希望拥挤在三级医院而不愿意去社区医院，这就是政府对医院资源引导不利造成的，这个不
利不仅仅体现在医生的资源合理安排上，更体现在对社区医院的扶植力度上。因此，排队系统要形成规模靠一两家三级医院搞一个IVR接接电话来搞，不符合市
场化的做法，只能属于医院门面工程，这个门面工程模式根本不应该讨论，我们要讨论的如何做一个可市场化的医院排队系统，这就是我问过医院很多相关人员的
原因，市场化医院排队系统第一前提就是公信力。公信力的塑造最好来自政府。
On 8月24日, 下午5时24分, Q <happys...@gmail.com> wrote:
> 本身排队的问题就是两方面的，一方面反应企业资源分配不够合理，一方面必定是排队客户的满意度下降。对于医院来说，他们愿不愿意花费成本在于如何看待这个问题， 如果觉得自己根本不必担心自己的市场，客户自己送上门，也不担心自己的资源是否合理，甚至还害怕过于合理而造成的不“和谐”，他们可能确实不会考虑去解决排队的 问题。
> 你说我假设的业务模式的“不符合市场行为”，并且是问过“很多”相关人员，而且是“一致”表态，对此我深感无语，不知道这相关人员都是哪些，为什么会如此一致。 因为就我亲身经历，就用过医院的这种服务，电话挂号，只是它用一种简单的排队系统，告诉你一个号，告诉一个去医院的时间范围，虽然通常这个时间点估计的很不准确 ，去了以后还是要现场排队等。如果他们能够预计地准确些，让我少等些时间，至少能够提升我个人的感知。
>
> 2009/8/24 interstage <buer0...@gmail.com>
>
>
>
>
>
>
>
> > 如果一家医院单独这样去做，实在太傻了，他自己的门诊资源已经很饱和了，病人在现场排队已经都满足不了了，医院不可能为了解决远程排队再另花成本，为病人减少排 队等候的时间，不是医院所考虑的。让医院做远程排队的前提是他的门诊资源不饱和，让病人多来占这些资源。因此医院单独来做，不符合市场和商务规则。但对政府和商 业企业做排队系统意义就不一样，政府来做医院排队系统，意义在于优化区域内的医院门诊资源和减少老百姓的排队时间，属于民生工程；商业企业做排队系统意义在于， 商业企业可以通过市场化手段先批发出区域内的医院门诊资源，再以零售方式卖给老百姓，同时在其他资源上获取商业资源，属于市场行为。
> MSN: happys...@hotmail.com
> ttnn:http://ttnn.appspot.com
John Wang
刚完成了一个证券项目，里面包含数据中心概念、相关应用，个人感觉如果说项目是BI项目的话，从外延上说也是可以的
BI是BI，BI又不是BI，:)