| 静韵 的个人资料小林记照片日志列表 |  工具  帮助 |
|
|
小林记FIGHTING~ 8月8日 （转摘）站在中年的极点上站在中年的极点上
峰岭 刊发时间：2009-08-08 07:46:10 文摘报
像被河水冲刷的船，你仓促地到了中年。体态、面容、眼神、心境都被盖上了中年的印戳。回头望去，乌飞蝉噤、红枯绿瘦，青春已溜得不见踪影；向前看去，鹤发鸡皮、枯萎蹒跚正在逼近。
中年和正午有些相似：凝重、深邃、空旷，是生命曲线上的一个极点。站在这儿，来路一览无余，去路上能搅出的动静也大致不出其右了 人们赋予这个年龄的关键词是“成熟”，可生活仍会硌疼你：家人生病你担心，孩子不听话你生气，工作出错你沮丧，没钱了你发愁……只是你学会了警惕这些灰色霉菌，不再给它们发酵生长的机会了。 在你这个年龄，左手要拽着孩子，右手要搀着父母，你成了他们两边的家长。女儿刚踏进青春期，像一只迷乱的羔羊，背上还驮着10斤重的书包。她还那么脆弱，说话稍不对劲就会戳伤她。父母呢，个头缩得那么矮，走路一摇三晃的，你还忍心对他们发牢骚吗?爱人跟你一样，也在中年的河流上忙着捕捞。 所以，你得有自我疏通和修补的能力。你得维护你一贯的形象：大大咧咧，乐乐呵呵。 这些年来，你受到岁月和生活的双重镂刻，内心也在不停地改变。沧海桑田，有的地方已经变硬了，有的地方却柔软了。从前你是树叶，环境是风，它一吹你就动。你跟着别人赶东赶西去上补习班，今天英语，明天文秘，后天管理，像猴子掰包谷。宴会上硬着头皮喝酒，却让胃痉挛不止。你在外边温文尔雅，在家里龇牙咧嘴，长着一身倒刺。你只想让社会接纳你，却不清楚自己要什么。 那时，你生活的姿势是引颈远眺。上学的时候盼毕业；女儿小的时候巴不得她长大；工作的时候想退休；在乡野时憧憬都市，追到了都市又怀念乡野。总之真正的生活在山的那一边。现在你却后悔自己错过了好些生活。在日历被撕了一大半后你才学会了调整焦距，对准眼前。 于是，你能听进父母的唠叨了，愿意陪他们散步了，也知道了拉他们去吃这吃那。发了奖金不再直奔化妆品柜台，而是会给爱人买一双柔软的牛皮鞋。你会带女儿奔到青岛看一回大海，冲到上海去看一场F1比赛，在她最想圆某个梦而你又有能力的时候帮她圆了，因为梦也会凋谢。你学着把菜炒香，把汤熬得很鲜，你通过这些小事去传递爱。 你知道，也许过不了多久，今天还围着餐桌的父母将无踪可觅。女儿很快也会张开翅膀去寻找自己的天空。她将不会每天一回家就拽着你的衣襟给你“播报”班上的新闻，也不会再往沙发上一躺，就把臭脚丫往你怀里塞了。 现在，你会把一件衣服穿好几年，把一部手机用到无法再用，你想在这套旧房子里一直住到老。越来越多的同事已经开着自己的车上下班了，你却干脆连班车也不坐，改成了跑步上下班。由此你获得了一种自由和力量，你依赖的东西原来很少，生存其实并不困难。生活就是这样，当你退到了潮流的边缘，潮流反而成了不相干的背景。 你也能和自己的工作和平相处了，不像以前蚂蚱似地在各个行当里乱跳了。因为你明白了无论什么工作，都像一块布，各有其细致明艳的正面，也有粗糙暗淡的背面。到了中年，生命已经流过了青春湍急的峡谷，来到了相对开阔之地，变得从容清澈起来。 1月4日 Reprint:Organizing a kick-off meeting for your projectOrganizing a kick-off meeting for your project
A kick-off meeting can be a formal, highly organized event or an informal one-hour meeting. However, it is always a good idea for project managers to organize kick-off meetings for new projects. Why is it important to hold a kick-off meeting?
The goals and scope of a new project are generally established at the kick-off meeting. It is also an opportunity for the members of the team to meet and start working on the team-building process. As project manager, you should try to get all your team members to participate and interact. This will give the team a sense of unity and will help all involved to focus on the goals of the project. At the kick-off meeting you should try to accomplish all or most of the following objectives:
Whether the meeting is formal or informal, a two-hour gathering, or an all-day event, the project manager should note all the objectives to be achieved and prepare an agenda. The agenda acts as a reminder, structures the meeting, and lets all the team members know the items that need to be discussed. Let's suppose you are a project manager and you want to organize an informal kick-off meeting. Here's an example of an agenda you could send to all your team members in preparation for the meeting: Meeting Room 4 January 30, 2000 9:00-11:00 am
At the meeting, the project manager should be aware of the time he or she spends talking. It is important to involve all the team members in the discussions - let them explain what their thoughts are on the project, what they expect to contribute to it, and how they will achieve their goals. Discussing individual and team goals openly and clearly is the right way to securing general team commitment to the project. The next step is to get individual team members to commit to their specific objectives. It is unlikely that each member will commit or even attain all the objectives at this early stage, but, as project manager, you can schedule a follow-up meeting and set certain time limitations. The more involved individual team members are in the entire project, the easier it will be for the project manager to obtain a reasonable commitment. 9月4日 摘:售前顾问应该怎么做 总听见ERP 公司的SALES 在抱怨：这年头，大家都把价格叫得这么低，回扣却要给得那么高，生意还怎么做啊？万般无奈之下，只有降低服务水平。眼见着ERP 的产品一家一家的掉价，实施的案例失败的越来越多，似乎大家对ERP 也渐渐的失去了信心。可问题出在哪？在接触了一些公司的销售和售前人员以后，我逐渐发现了问题的根源。
·什么是售前咨询 什么是售前咨询 这似乎是个很简单的问题，售前咨询嘛，就是跟着SALES 出去打单（在这，我使用“打”字，的确是因为项目竞争的激烈程度不亚于打仗），带上笔记本电脑和投影设备，在客户那一顿吹，客户蒙了的时候项目就差不多 了。记得“清华夜话”里曾说了个笑话：最先进的开发工具不是汇编、C 或者BASIC，而是PPT。这PPT 就是给客户用POWERPOINT 做演示。 国内的ERP 顾问还有这么一手：拿演示产品。按照PPT 上的说明，对应着用ERP 系统走一遍，客户对软件也就了解了一二。对于大部分的售前顾问来说，这就是他们的全部工作。当然，按369 等来分，售前顾问也需要在适当的时候说适当的话，给SALES 做一做配合。可这够吗？ 调查用户的需求 业内比较通行的调查用户需求的方式包括： 1、提供标准的问卷 2、与具体负责人交谈 3、参观企业的实际运转 4、其他方法 产品的演示 所谓产品的演示就是在客户面前使用自己的产品，或按照客户的某些要求演示产品如何解决这些问题。 在演示的过程中顾问们常按照自己的想法去做：标准的流程是这样的，开销售定单，产生MRP，计算生产单，安排生产，安排采购……等等。然而，这并不是客户所希望看到的，他们需要了解的是：在我的企业中按照这种流程去走，你们的软件是如何解决？在此也对咨询顾问提出了另一个要求：随机应变的能力。演示前用户是不会告诉你，他会提什么问题，所以当用户问到这些特别问题的时候，顾问要从容不迫的解答，更重要的是能让他们理解。说了半天白说，呵呵呵，那就臭了。所以，咨询顾问必须了解多种企业的运作流程和管理方式，并能实际的运用到产品中。产品演示的目得在于：给客户以信心 ----你的需求，我们能够满足。 编写解决方案 最重要的部分就是编写解决方案了。打个比方：需求调研是后场截球，产品演示是中场传球，那么解决方案的编写就是临门一脚。这一脚打得好与坏，直接关系到整个项目能否成功完成。解决方案应该包括哪些 部分？在这里我就一般的格式作一个简单的介绍： 1、客户的简介 2、客户目前的信息化管理流程，并分析其优势和问题。 3、介绍产品的功能。 4、结合产品和客户的问题，谈解决方案。 售前顾问需要具备的条件 说了这么多，大家对售前顾问需要具备的条件已经有了个大概的了解，在这里我首先需要强调的却是前面所没有提到的----最重要的能力：对业务的捕捉能力。 售前咨询顾问的工作是配合销售人员的工作，正如我常对销售人员所说：你们在前面冲锋陷阵，我在后面摇旗呐喊。这言外之意就是，你们打得头破血流，我还是摇旗呐喊。可光喊够吗？客户需要销售三天内提交需求调研报告，而售前顾问却拖上两个礼拜----SALES 得急死。同样，当客户跟咨询顾问直接联系的时候售前顾问也应承担起销售的部分工作。在我的眼里，售前是*钱的工作，也不是没有道理的。用某个SALES 的话来说，售前的工作就是，给客户挖个坑，让他乐呵呵的往里跳，然后埋了。可你也得让他能乐起来呀。 其次，售前咨询顾问必须兴趣广泛。 第三，售前顾问必须有所专精。 第四，售前顾问必须有极强的沟通能力。 第五，文字的组织能力。 产品的价格为什么这么低 说了这么多，似乎自己忘了主题：为什么软件的价格这么低？因为，售前人员不懂得去挖掘客户的需求，因为售前人员不懂得向客户展示自己的产品。售前顾问只能停留在简单的“卖产品”的阶段，当所有的MRPII/ERP 产品结构和功能大致相同的情况下，唯一能用来竞争的也就只有价格了。而价格降低的同时，也就意味着服务质量的降低。对于客户来说，价格越低ERP 实施成功的可能性也就越低----软件公司的经营需要合理的利润支持，当他们都难以支持的时候，还能谈什么服务？ 试想：某个客户在提要求的时候只是需要进销存软件，但经过资深的顾问对其业务进行分析，挖掘出客户的需求其实是CRM（客户关系管理）和ERP 系统的结合，那么你认为他会只花2万块去买套所谓的ERP 吗？ 市场乱了，满天飞的是所谓的几千块的ERP 软件，他们的存在是有道理的，因为客户不懂，不懂SAP 和速达的区别，不懂ORACLE 和用友的差异----不过就是管仓库，管销售吗？不是都能进行统计吗？不都是做做财务报表算算成本吗？这个什么什么软件还能根据我的要求进行二次开发呢。可悲的是售前顾问不能向客户阐明，他需要的是什么、我能解决你什么问、为什么用我的产品值。 罗嗦罗嗦写了这么多，很多都是自己作PRESALES 的感慨----尽管自己做得很不好，呵呵呵，甚至是有些丢人，但我们这个TEAM 做得还不错。有个很强的LEAD，就象头狮子，领着头牛和一头猪（哦，好象我没有这么胖，算了，将就吧）。经验之谈的最后一点就是：团队合作！一个人的力量再强，也强不过一组人。组员之间能相互配合，协同共进将事半功倍。而这也就要求售前顾问能很好的与人合作，试想：连内部的事物都不能处理好，那还怎样去对外销售？ 总结 作为售前顾问，我有一个比较极端的想法：一切都以项目为主。知识再怎么丰富，项目书写得再怎样好，拿不到项目也是白搭。而售前与销售最大的差别就在于：销售不需要考虑成本----能拿下来就好了，而售前顾问必须考虑后续的成本。ERP 软件销售和其他商品不同，一个软件100 万可以卖、50 万同样可以卖，差异就在于解决了什么。 9月3日 Test in a datawarehouse environmentPost by Internet:
it includes three things. First, my transformations carry a , , , RowsInput, RowsOutput, RowsRejected and they are logged in my job_run table. If those numbers don’t match there may be something wrong with the transformation process. In the case of Rows, it may well be the case that RowsOutput + RowsRejected <> RowsInput. You can have some grouping of rows into a single output row. If you don’t have groupings, then they should match. In the case of , it should add up.
Next, I compare what is in the data warehouse ( and rows) to what occurred in the transformation process.
Lastly, I like to compare the source system values to the data warehouse. The first two I call validation and the last one I call reconciliation(校正). These two things should be done with every run.
Now that leaves you with a process to deal with the rejected rows. They could be rejected because of bad data or because they don’t meet the criteria to enter the data warehouse. Without knowing the application, I don’t think I can give much more of an answer. Another Post: Joe Oates’ Answer: Though I do not know of any non-proprietary data warehouse test plans that are available, gantthead.com does have some generic test plans and advice available. The key areas that must be tested are the ETL programs, SQL queries, presentation tool queries and programs, stored procedures or queries that produce aggregate or summary tables. You should have a non-changing set of source test data as well as data warehouse test data that you or other team members can be assured of reproducible results. The ETL testing should follow principles of any testing including boundary tests, format tests, valid contents tests, etc. It is a good idea to include invalid data for all of the just mentioned types of tests. The SQL queries can be validated by importing data that has been loaded by the ETL process into a spreadsheet program to validate calculations and totals. Presentation tool queries and reports can be validated by hand writing SQL queries or using a spreadsheet program to validate the presentation tool output. The key to testing the data warehouse software is to know the data that will be tested and what the answers are supposed to be. One of the techniques that many teams find very successful is to have people for all of the areas of project get together (be sure to include knowledgeable users) and suggest specific things that can be wrong and write them on a board. Rank them as being highly damaging, moderately damaging and not very damaging. Write test scripts for the highly damaging items first, followed by the moderately damaging and not very damaging. Use this to organize how you write the test plans. Testing cannot guarantee that there will never be any errors. There are just too many combinations and permutations that it is not practical to test each one. However, by ranking the types of errors as suggested above, you will avoid wasting time on creating test scripts and test scenarios for less important possibilities and not having time to create test scripts and test scenarios for possibilities in which errors could significantly diminish or destroy the value of the data warehouse to the users. 8月19日 ABC法则
|
||||||||||
|
|
