nodejs将PDF文件转换成txt文本,并利用python处理转换后的文本文件 - Boom__Clap - 博客园

mikel阅读(1049)

来源: nodejs将PDF文件转换成txt文本,并利用python处理转换后的文本文件 – Boom__Clap – 博客园

目前公司Web服务端的开发是用Nodejs,所以开发功能的话首先使用Nodejs,这也是为什么不直接用python转换的原因。

由于node对文本的处理(提取所需信息)的能力不强,类似于npm上的包:‘linebyline’、’lineReader’,处理能力都不强,所以使用python来处理。

 

目的:提取PDF中带有‘检查’字样的文本(行)

思路:

1、Nodejs 找到PDF转换text的包,转换,将text文本信息发送到Python服务器。

2、创建一个简单的Python服务器,接收并处理text文本,得到所需要的文本信息,打包成Json并发送到Node服务端。

3、Node服务端接收到后,再发给前端页面将信息展示。

 

好,那首先我们要去npm官网上找到转换用的包,pdf-textstring是一个不错的包,测试之后,大部分PDF都可以成功转换成text文本,但是有个别文件转换不成功,所以还需要换一个,最后是使用了’pdf2json‘这个包,在npm 上找包,有一个要点,就是包名很短,功能很多,类似的处理功能会集中在某个包上,但是包名可能只是其中一种功能。

 

PDF文件样本:

 

转换代码:

复制代码
 var fs = require('fs'),
     PDFParser = require("pdf2json");

 var pdfParser = new PDFParser(this, 1);
pdfParser.loadPDF("tmp/testpdf.pdf");
pdfParser.on("pdfParser_dataError", errData => console.error(errData.parserError)); pdfParser.on("pdfParser_dataReady", pdfData => {
     data = pdfParser.getRawTextContent()
     console.log(‘文本信息:’+data)
 });
复制代码

 

转换后的文本信息:

复制代码
操作任务: 3号主变压器带10kVB、C母全部负荷,2号主变压器停电,2号主变压器、162-2隔 
 
 
 
离开关、170、802断路器由运行状态转换为检修状态,110kVB母由运行状态转换为检修状态 
 
 
 
顺序 操 作 项 目 √ 时间 
1 投入10kVB、C母分段820闭锁备自投压板   
2 退出10kVB、C母分段820备投跳803压板   
3 退出10kVB、C母分段820备投合820压板   
4 检查2、3号主变压器分头位置一致   
5 合上820断路器   
6 检查820断路器确带负荷   
7 检查2号、3号主变压器负荷分配正常   
8 拉开802断路器   
9 检查802断路器在分闸位置   
10 检查3号主变压器不过负荷   
11 合上12中0中性点接地刀闸   
12 检查12中0中性点接地刀闸在合闸位置   
13 检查802断路器在分闸位置   
14 将802-3手车由运行位置拉至试验位置   
15 检查802-3手车到位指示正确   
16 将802手车由运行位置拉至试验位置
复制代码

 

Node服务端将转换后的文本信息发送到Python服务端:

复制代码
//Node发送数据并接受返回的处理后的数据

PDFPARSER(data, function(err, result) {
var test = unescape(result.replace(/\\u/g, ‘%u’))//解python端传来的unicode
res.send(ERRCODE.MakeResult(ERRCODE.OK, JSON.parse(test)));//JSON.parse一次,将解后的字符串换转成Json,发给前端
return;

});

//发送数据的函数

var PDFPARSER = function (reqData, callback) {
    var buf = new BUFFER.Buffer(reqData);
    var op = {
        host: "127.0.0.1",
        port: 8087,
        method: 'POST',
        path: "/",
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded',
            'Content-Length': buf.length
        }
    };

    var req = HTTP.request(op, function (res) {
        var recvData = "";

        res.on('data', function (chunk) {
            recvData += chunk.toString();
        });

        res.on('end', function () {

            if (callback) {
                callback(null, recvData);
            }

        });
    });

    req.on('error', function (e) {
        console.log(e);
    });

    req.write(reqData);

    req.end();
};
复制代码

 

Python服务端接受并处理、返还数据:

复制代码
import sys 
import codecs
import SimpleHTTPServer
import SocketServer
import json
import re
from urlparse import urlparse
from urlparse import parse_qs

PORT = 8087

class Handler(SimpleHTTPServer.SimpleHTTPRequestHandler):
    def do_GET(self):
        pass#print self.headers
        
    def do_POST(self):
        #print self.headers
        
        contentLength = int(self.headers["Content-Length"])

        textString = self.rfile.read(contentLength)
        s = textString.split("\n")

        test = []
        for fileLine in s:
            if u'检查' in fileLine:
                line_pattern =r'\s*\d+\s?(.*)'
        
                def func(text):
                    c = re.compile(line_pattern)
                    lists = []
                    lines = text.split('\n')
                    for line in lines:
                        r = c.findall(line)
                        if r:
                            lists.append(r[0])
        
                    return '\n'.join(lists)
        
                
                result = func(fileLine)
                test.append(result)
        print test
                
        self.send_response(200)
        self.send_header('Content-type','text/plain')
        self.end_headers()
        #print result.decode("utf-8")
        #print result
        test = {"CZBZ": test}
#这里test的格式是因为前端页面接收数据的格式需要
        self.wfile.write(json.dumps(test) )
                
        

        



if __name__ == "__main__":
    reload(sys)
    sys.setdefaultencoding("utf-8")
    httpd = SocketServer.TCPServer(("", PORT), Handler)
    print "serving at port", PORT
    httpd.serve_forever()
复制代码

 

Python处理后的数据:

复制代码
{"CZBZ":['\xe6\xa3\x80\xe6\x9f\xa52\xe3\x80\x813\xe5\x8f\xb7\xe4\xb8\xbb\xe5\x8f\x98\xe5\x8e\x8b\xe5\x99\xa8\xe5\x88\x86\xe5\xa4\xb4\xe4\xbd\x8d\xe7\xbd\xae\xe4\xb8\x80\xe8\x87\xb4   \r', '\xe6\xa3\x80\xe6\x9f\xa5820\xe6\x96\xad\xe8\xb7\xaf\xe5\x99\xa8\xe7\xa1\xae\xe5\xb8\xa6\xe8\xb4\x9f\xe8\x8d\xb7   \r', '\xe6\xa3\x80\xe6\x9f\xa52\xe5\x8f\xb7\xe3\x80\x813\xe5\x8f\xb7\xe4\xb8\xbb\xe5\x8f\x98\xe5\x8e\x8b\xe5\x99\xa8\xe8\xb4\x9f\xe8\x8d\xb7\xe5\x88\x86\xe9\x85\x8d\xe6\xad\xa3\xe5\xb8\xb8   \r', '\xe6\xa3\x80\xe6\x9f\xa5802\xe6\x96\xad\xe8\xb7\xaf\xe5\x99\xa8\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa53\xe5\x8f\xb7\xe4\xb8\xbb\xe5\x8f\x98\xe5\x8e\x8b\xe5\x99\xa8\xe4\xb8\x8d\xe8\xbf\x87\xe8\xb4\x9f\xe8\x8d\xb7   \r', '\xe6\xa3\x80\xe6\x9f\xa512\xe4\xb8\xad0\xe4\xb8\xad\xe6\x80\xa7\xe7\x82\xb9\xe6\x8e\xa5\xe5\x9c\xb0\xe5\x88\x80\xe9\x97\xb8\xe5\x9c\xa8\xe5\x90\x88\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5802\xe6\x96\xad\xe8\xb7\xaf\xe5\x99\xa8\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5802-3\xe6\x89\x8b\xe8\xbd\xa6\xe5\x88\xb0\xe4\xbd\x8d\xe6\x8c\x87\xe7\xa4\xba\xe6\xad\xa3\xe7\xa1\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5802\xe6\x89\x8b\xe8\xbd\xa6\xe5\x88\xb0\xe4\xbd\x8d\xe6\x8c\x87\xe7\xa4\xba\xe6\xad\xa3\xe7\xa1\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5170\xe6\x96\xad\xe8\xb7\xaf\xe5\x99\xa8\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5170-2\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5170-3\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5162-3\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5162-2\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5170-2\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5170-20\xe6\x8e\xa5\xe5\x9c\xb0\xe5\x88\x80\xe9\x97\xb8\xe5\x9c\xa8\xe5\x90\x88\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5170-3\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5170-30\xe6\x8e\xa5\xe5\x9c\xb0\xe5\x88\x80\xe9\x97\xb8\xe5\x9c\xa8\xe5\x90\x88\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa51B9\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa51B90\xe6\x8e\xa5\xe5\x9c\xb0\xe5\x88\x80\xe9\x97\xb8\xe5\x9c\xa8\xe5\x90\x88\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa5162-2\xe9\x9a\x94\xe7\xa6\xbb\xe5\xbc\x80\xe5\x85\xb3\xe5\x9c\xa8\xe5\x88\x86\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r', '\xe6\xa3\x80\xe6\x9f\xa51B10\xe6\x8e\xa5\xe5\x9c\xb0\xe5\x88\x80\xe9\x97\xb8\xe5\x9c\xa8\xe5\x90\x88\xe9\x97\xb8\xe4\xbd\x8d\xe7\xbd\xae   \r']}
复制代码

C#读取PDF文档文字内容 - tzdk - 博客园

mikel阅读(1205)

来源: C#读取PDF文档文字内容 – tzdk – 博客园

C#读取PDF文档文字内容

通过iTextSharp读取PDF文件内容,下载地址,下载后解压itextsharp-dll-core.zip。

只能读取英文和数字,文档中包含的汉字无法正常读取:

复制代码
private string ReadPdfContent(string filepath)  
{  
    try  
    {  
        string pdffilename = filepath;  
        PdfReader pdfReader = new PdfReader(pdffilename);  
        int numberOfPages = pdfReader.NumberOfPages;  
        string text = string.Empty;  
  
        for (int i = 1; i <= numberOfPages; ++i)  
        {  
            byte[] bufferOfPageContent = pdfReader.GetPageContent(i);  
            text += System.Text.Encoding.UTF8.GetString(bufferOfPageContent);  
        }  
        pdfReader.Close();  
  
        return text;  
    }  
    catch (Exception ex)  
    {  
        StreamWriter log = File.AppendText(System.AppDomain.CurrentDomain.SetupInformation.ApplicationBase+"\\log.log");  
        log.WriteLine("出错文件:" + e.FullPath + "原因:" + ex.ToString());  
        log.Flush();  
        log.Close();return null;  
    } 
}
复制代码

 

可以读取中英文

复制代码
private string OnCreated(string filepath)  
{  
    try  
    {  
        string pdffilename = filepath;  
        PdfReader pdfReader = new PdfReader(pdffilename);  
        int numberOfPages = pdfReader.NumberOfPages;  
        string text = string.Empty;  
  
        for (int i = 1; i <= numberOfPages; ++i)  
        {  
            iTextSharp.text.pdf.parser.ITextExtractionStrategy strategy = new iTextSharp.text.pdf.parser.SimpleTextExtractionStrategy();
            text += iTextSharp.text.pdf.parser.PdfTextExtractor.GetTextFromPage(pdfReader, i, strategy);
        }  
        pdfReader.Close();  
  
        return text;  
    }  
    catch (Exception ex)  
    {  
        StreamWriter wlog = File.AppendText(System.AppDomain.CurrentDomain.SetupInformation.ApplicationBase+"\\mylog.log");  
        wlog.WriteLine("出错文件:" + e.FullPath + "原因:" + ex.ToString());  
        wlog.Flush();  
        wlog.Close();return null;  
    }  
  
}
复制代码

 

经典企业管理软件商业模式 - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(1837)

来源: 经典企业管理软件商业模式 – 阿朱=行业趋势+开发管理+架构 – CSDN博客

经典企业管理软件商业模式

咱们假设年销售额目标50亿-100亿。

一、渠道
1、全国除去香港/澳门/台湾(生意先不发展那里)、西藏/新疆/宁夏/青海(大城市太少)不说,直辖市北上广、天津重庆,还有华北(河北/山西/内蒙古)、东北(辽宁/吉林/黑龙江)、华东(山东/江苏/安徽/浙江/福建)、华中(湖北/湖南/河南/江西)、华南(广东/广西/海南)、西南(四川/云南/贵州)、西北(陕西/甘肃),一共5个直辖市、23个省。

2、全国一共600多个市(有准确的国家行政统计数据/县级市也算市),咱们把直辖北上、广深、天津重庆除外,其他城市按规模和经济实力咱们分三档:第一档100个城市,第二档200个城市,第三档300个城市。

咱们就算每个城市发展一个代理商,那就需要100-200个代理商(第三档都是弱小县级市了不支撑大销售,咱们80/20看事),平均到每个省需要找5-10个代理商。每个代理商需要负担:
A、100个代理商,50亿,每个代理商年目标5000万
B、100个代理商,100亿,每个代理商年目标1亿
C、200个代理商,50亿,每个代理商年目标2500万
D、200个代理商,100亿,每个代理商年目标5000万

二、客户
1、中国赚钱的行业大约40多个(可统计中国企业500强/中国民营企业500强),而且最老最成熟的SAP在全球也就拥有20多个行业解决方案(做不大的行业都没有专门的解决方案)。

2、按照80/20,塔尖客户还是每个行业的500强,中间一级是500强外-1万名的企业,其他1万开外的企业都是塔基企业。

咱们算大数,40个行业x500强=20000个客户。再简单粗暴说23个省,那每个省就分布大约100个中国500强客户(当然很多强客户的总部在直辖市和一级城市)。

但其实不可能每个行业都能扎的这样深把每个行业500强都覆盖到,所以主力覆盖的行业也就是20来个,这样就10000个客户,这样每个省平均分布50个500强客户。再说每个省需要找5-10个代理商,那么每个代理商需要Care 5-10个500强客户,差不多能Care过来。

看客户平均产值:
A、100个代理商,50亿,每个代理商年目标5000万,每个代理商Care 10个500强客户,每个客户需要每年产出大约500万。
B、100个代理商,100亿,每个代理商年目标1亿,每个代理商Care 10个500强客户,每个客户需要每年产出大约1000万。
C、200个代理商,50亿,每个代理商年目标2500万,每个代理商Care 5个500强客户,每个客户需要每年产出大约500万。
D、200个代理商,100亿,每个代理商年目标5000万,每个代理商Care 10个500强客户,每个客户需要每年产出大约500万。

三、产品与服务

1、每个软件公司不能研发太多产品,否则整个产业链(营销/销售/实施/项目管理/培训/定制开发/服务/运维)成本和复杂性都很高,代理商能力不匹配质量不达标。所以核心产品5个,次核心产品5个就OK。

产品不宜上中下都提供,不能一套产品提供豪华版/标准版/基本版,看似裁裁剪剪就OK,其实不可以。每层次客户的要求都不一样,对产品/营销/销售/实施/服务/定制是一整套匹配的不一样,每个代理商也做不到上能做塔尖客户下能做塔基客户的弹性能力。

2、软件价格和软件复杂度也有一定关系,软件复杂度也和客户层次有一定关系(塔尖客户/中间客户/塔基客户对软件复杂度和价格承受力均不同)。软件复杂度和价格也影响代理商能力要求和销售难度。依中国目前渠道商数量和能力,每个产品价格应该在10万-50万,这样一整套套件产品就是100万-500万。这也是普遍客户承受能力,上能覆盖每行业500强,下能覆盖中与中上行业客户。塔基客户只能放弃。

3、服务产品分为:
实施(高级流程梳理服务产品/实施安装配置服务产品/项目管理服务产品)、

服务(培训认证服务产品/试点应用服务产品/推广应用服务产品/客服问答服务产品/配置变更服务产品)、

运维(安全性能运维监控检查优化服务产品/数据检查修正清洗处理服务产品/升级迁移扩容技术服务产品/疑难技术支持服务产品)、

定制开发(新功能、新查询/新报表、系统整合/门户集成、原有UI修改、原有功能业务逻辑修改、BUG修改)

4、收入结构配比:
软件收入+License收入30%,实施收入20%,服务收入20%,运维收入20%,定制开发收入10%。

定制开发成本高利润低/知识人员管理难,所以不鼓励大规模团队定制。可以外包、可以化整为零来控制成本。为了做到能够外包、能够化整为零,需要功能代码自我封闭性/可阅读性/异常截获性强、平台API/定制开发平台/开发模板强、升级工具强,还要跟随开发文档、培训教育认证、定制开发支持。所以目标明确后就得配套所有端到端相关。

5、客户收入配比:

一套套件软件产品为5-10个子产品,每个子产品10-50万,一套套件软件产品为100-500万。这样来思考分配到一个客户一个子产品的综合产出与售价。

A、100个代理商,50亿,每个代理商年目标5000万,每个代理商Care 10个500强客户,每个客户需要每年产出大约500万。500万分为150万软件收入、100万实施收入、100万服务收入、100万运维收入、50万定制开发收入。

B、100个代理商,100亿,每个代理商年目标1亿,每个代理商Care 10个500强客户,每个客户需要每年产出大约1000万。1000万分为300万软件收入、200万实施收入、200万服务收入、200万运维收入、100万定制开发收入。

C、200个代理商,50亿,每个代理商年目标2500万,每个代理商Care 5个500强客户,每个客户需要每年产出大约500万。500万分为150万软件收入、100万实施收入、100万服务收入、100万运维收入、50万定制开发收入。

D、200个代理商,100亿,每个代理商年目标5000万,每个代理商Care 10个500强客户,每个客户需要每年产出大约500万。500万分为150万软件收入、100万实施收入、100万服务收入、100万运维收入、50万定制开发收入。

四、能力跟随

1、总部:需要在平台、模板、流程、自动化工具、全国管理平台上发力,投入精英高科技人才。

还需要做好品牌塑造、营销/销售/实施/服务/运维/开发标准制定、标准培训认证/督导/支持,管理好合同风险/回款风险

2、成立企业大学/和大学合办课程,做好人才吸引/培养/输送,做好渠道商营销/销售能力培训、实施/服务能力培训、技术运维/技术开发能力培训

五、实例分析

咱们分析,战略是:
1、产品:大力做强产品(财务、SCM、CRM、HR、OA)、大力做强服务标准产品、大力做强定制开发平台产品和配套

2、标准:大力做强品牌,大力做强各业务线标准制定/培训认证/督导/支持

3、大力做能力提升:渠道商营销/销售能力培训、实施/服务能力培训、技术运维/技术开发能力培训

4、大力扩张渠道战略:力求扩张到200个大渠道代理商

假设现在年收入10亿,要在10年内要达到年销售额50亿-100亿,按年复合增长率25%速度增长(考虑速度管控风险/能力成长/人工成本增长/营销销售费用增长/办公租金增长/税金增长/客户持续购买能力),来倒推需要多少年来实现。这个年限也决定了在这些有限时间内每年要明确做到哪些大事。

就算需要10年完成,那上述4类大事,每类都最少需要2.5年必要时间,这很紧。不过做事我们从来都不是线性的,而是配比同步增长的,所以会持续同比夯实与扩张,这就是健康的。

额外,再想想另外一家做各种主流行业解决方案的软件集团企业,号称年销售额60亿,主要收入却来自欧美日外包,把美元换算成人民币统计来提高年收入,本身国内各主流行业解决方案从开发到实施到服务到客服做了N多也收入才20亿(差不多一个行业平均下来2亿),其他收入来自电子硬件销售。所以回头想想就做国内市场,纯做解决方案(不卖硬件),要做到50亿-100亿,要有多难、利润要有多低,如果不压榨成本,就是优化最精确的战略规划/最精确的计划执行PDCA管理和预算管理,这运营能力得要求多强。
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/17733183
版权声明:本文为博主原创文章,转载请附上博文链接!

企业应用软件商怎么渡劫 - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(1258)

来源: 企业应用软件商怎么渡劫 – 阿朱=行业趋势+开发管理+架构 – CSDN博客

企业应用软件商怎么渡劫

云这个概念从2006年由Google提出,Google的信息爬取爬虫、内容存储、内容索引、搜索运算,无时不刻的让我们感觉到云计算和云存储的强大性。传闻Google已经拥有一百万台服务器,这么密集的服务器,需要的电力/通风/散热、高集成安装放置、数据传输/服务器分布式协同运算、监控运行/硬件损坏/替换,这得多高的技术要求。所以听说Google自己研发服务器主板为了更高密集放置,自己设计机房为了全自动化运维/机器人替换损件,用海水循环制冷散热/用潮汐来产生电力,自己研发新的数据传输协议/自己研发铺建新的数据传输缆线介质,自己研发操作系统研发数据库研发开发语言研发中间件并且开源,而且还把这些从基础硬件/网络/存储/软件都开放出来供大家分享使用,这就是云的起源。

后来Amazon为了搞开放商家平台,为了商家的数据/图片的存储,为了销售数字化的电子书/音乐/数字电影的存储和传输,所以Amazon也发展了云计算/云存储业务。

但2013年才应该是中国云计算元年,这已经距离2006年过去了7年了。2013年,国际巨头Oracle整个公司全方向转云/大力收购大力研发云/并且加大对云的销售业绩要求和提成激励,IBM云进入中国、微软云进入中国、Amazon云进入中国,SAP大力推广私有云HANA高性能软硬一体化的数据仓库/商业智能。中国各大巨头如华为、联想等也加入国际开源OpenStack云组织,中国互联网巨头BAT/360都进入云市场,并且去年掀起一股消费云大战那就是网盘/相册,从免费赠送100G竞争到了免费赠送10个T。在企业应用云,金蝶的主打中端产品K3也演变成K3 Cloud,是全新研发的一代产品,完全基于云来设计而非过去K3的改造。用友也研发了云应用管理平台Cloud Service Platform。东软也在2014年初宣布以后在主力行业推进云,东软扎的行业可都是政府、事业性等对安全对私有敏感的组织(如国土资源、电信、电力、公安、税务、审计、社保等等)。2013年最让人震惊的还是Amazon与美国中情局签订云服务的提供,这可是安全保密极高的美国安全军方,对于对云有安全担忧的人们无疑是一剂强心剂。

云虽然在IaaS 网络虚拟化/存储虚拟化方面还有许多技术深化、在关系型数据存取领域还缺乏重磅分布式产品、在开发语言领域Golang还不成熟、在应用引擎研发方面还不丰富不稳定不强大、在运维服务管理方面还响应不足/解决问题不足、解决方案在开源界还尚不成熟,但,这是IT行业,3年一小变,5年一大变。所以从2013年算起,2017年将是中国云计算爆发的一年。

科技的进步是相对比较快的,但应用落地普及往往受客户进步的影响,客户走不动你就很难动。但纵观中国企业信息化20年,很多重大阶段的升级往往不是受客户驱动,而是受巨头推动。Oracle已经决定云优先,也就是销售组织侧重云、销售业绩份额偏重云、销售提成激励偏重云,所以Oracle的销售先给客户推荐云讲解云营销云。

巨头的推动力量是巨大的,就如同中国金融业一直很封闭的自己玩,现在BAT年底一轮利率热、理财基金热,短期聚集了万亿资金。这让保守金融业从未有过的震惊。怎么世界变成这样的玩法了?老百姓难道疯了?纷纷举办内部研讨会、给媒体吹风给老百姓吹风宣传风险担忧漏洞,但却仍然势不可挡。就如同中国电信业,过去三大巨头,现在虚拟运营商纷纷获得牌照应用花样眼花缭乱。就如同中国出租车业,几十年没什么变动,去年第四季度打车软件补贴大战互联网巨头砸10亿真金白银,顿时出租车业天翻地覆。再比如中国如家之于中国宾馆业,携程之于中国民航机票销售业一样。这就是巨头的资本力量+媒体传播营销力量+消费者流量入口力量+地推力量+信息数据收集/应用研发力量。这就是巨头的砝码。

中国企业客户应用科技是一向保守的,但这几年京东、阿里攻城略地,让线下制造商、分销商、零售商纷纷压力巨大,有的关店,有的多渠道销售,有的转型主力线上。这都是生死痛苦蜕变。谁能料到线上发展这么快,而且革命了线下,让线下无路可走。现在这些互联网巨头又在准备革命服务业,先从餐饮团购、电影院/KTV/美容院/度假村/游乐园开始。传统巨头惊了,什么叫互联网思维,怎么转?联想、万科、华为、海尔纷纷在探讨、领队参观学习。

而云计算也是如此。不仅互联网巨头们业务应用一体化变革整个行业的商业模式与业务流程,而且人家利用云存储获得了整个闭环业务链条的全社会的业务数据,这对重组、优化、配置社会资源,让社会资源更加高效率高价值非常有利。

我们做传统应用软件的目的不就是为了企业资源配置、组合更加高效率高价值么?我们局限在某个企业内部信息收集、某个企业内部资源的整合优化。而人家互联网一上手就是整个社会资源,我们的某个具体客户就是人家社会资源中的一份子。我们是小圈,人家是大圈。

企业经营讲究的是根据市场动态来决定自己的战略战术决策,所以最关键的信息反而是企业外/社会内的信息,而非企业内部的信息收集利用。所以我们做传统企业应用软件一开始就低了一维。

有句夸张的话就是未来每个企业都是电子商务企业,每个企业都会成为一个软件企业要充分利用软件信息技术来为自己经营而引领并支撑。虽说这个未来可能还不确定有多远,可能一些企业如媒体、出版、金融、旅游、机票/火车票、宾馆、打车、餐饮、休闲娱乐、购物、数码、家电、教育、医疗、农业养殖种植都被充分颠覆了,更多的行业也正在被逐步颠覆重新想象。但中国仍然太大,中国企业太多,中国三教九流的水平层次太杂。这么多的颠覆,仍然是大量企业在权钱寻租交易、跑马圈地、暴力营销、逐水草而居。所以中国传统企业软件也很多层次很多路仍然可行。

但云这个坎怎么迈?

我过去反思过传统企业软件的核心竞争力,有人讲应该是渠道销售与服务能力,有人讲应该是产品研发品质,有人讲应该是整个业务价值链的整合管理,有人讲是品牌溢价议价能力、有人讲是软件内嵌灵魂思想模型引领指导能力、有人讲是客户需求快速探知与满足。

我觉得这都对。但就是没人讲中国传统企业应用软件的核心在于技术。

你看看云。你要满足海量用户的运行和数据存储,这比给一家家企业安装部署软硬件要高门槛的多。大量传统企业应用软件商,只要客户的数据大点人多点,IT系统就不稳定/性能慢。虽说中国传统企业应用软件都研发自己的所谓企业应用平台,但结果就这现状。

那在云时代怎么应对?所以必然要把自己所谓的企业应用平台经过裁剪,放置到现在专业的云提供商那里。

企业应用平台其实内在分很多层,最底层应该是技术平台。过去搭建企业应用平台,如在微软技术体系内,微软提供了报表服务引擎、工作流服务引擎、消息队列引擎、服务接口管理引擎、数据ORM存取引擎、事务引擎、日志记录、异常跟踪监控等等。再往上是真正的企业应用基础,如单点登录门户、组织权限管理、主数据管理、基础业务参数开关维护。再往上走是新模块可视化设计工具/典型功能代码框架、定制开发工具/补丁打包发布工具/补丁升级工具、实施安装部署工具/数据初始化工具、运维检查监控优化工具/技术支持工具。

所以说,专业的云提供商会替代了企业应用平台中的技术平台部分。你看云提供商提供的文档存取数据库、图片存储数据库、视频存储、KV数据存储、语音识别引擎、图片识别引擎、消息队列引擎、地图引擎,这些高难度技术都是中国传统企业应用软件商干不了的。所以只能干脆利用人家的引擎。

未来,能做企业应用平台的寥寥无几,全被高技术门槛打死了,不像现在各种OA、BPM、快速开发平台等等各种李逵李鬼都纷纷宣称自己是平台。

彻彻底底扯下技术遮羞布的中国传统企业应用软件商,放到云上面大大自动化简化实施/运维/支持,在这种未来现状下,什么是中国传统企业应用软件商的核心竞争力呢?在这种局面下我们不妨再问自己一下这个问题。客户需求快速探知与满足能力?软件内嵌灵魂思想模型引领指导能力?品牌溢价议价?产品研发品质?渠道销售服务?业务价值链的整合管理能力?

到底哪个能力是第一呢?有人说当然是客户需求快速探知与满足能力?这是生意的本质根源啊。但你做了什么能够做到这一点呢?有人说是业务价值链整合管理能力?那你又做了什么能够做到这一点呢?我们不妨多问问我们自己。
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/20222193
版权声明:本文为博主原创文章,转载请附上博文链接!

简化ERP - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(1271)

来源: 简化ERP – 阿朱=行业趋势+开发管理+架构 – CSDN博客

简化ERP

一、简化企业:
1、组织管理:小团队、小项目周期制。依中国人普遍人的能力,只能做小周期小人手团队的事,事情一复杂/团队一大了就搞不定了

2、流程原则1:放弃强力管控导向,减少层层道道的审批/信息屏蔽
3、流程原则2:让流程环节均衡化,不能让业务处理堵在几个瓶颈岗位/瓶颈时段

二、简化ERP功能设计:
1、输入原则1:场景化功能设计,为每个业务场景定义最小的输入输出
2、输入原则2:不输入,尽量使用各种传感器
3、输入原则3:注重企业上下游链条合作伙伴信息化连通,避免重复输入数据和口径不一致

4、输出原则1:从管理、决策需要的输出信息角度来反向看需要输入什么
5、输出原则2:不输出,设立自动预警上下阀值以及自动通知流程,只管理异常情况不事事都管、不同级别人管理不同级别的异常不要一窝蜂

三、简化ERP技术:
1、利用开源技术框架开发,不从零自我研发

2、利用云服务商提供的技术引擎,不从零自我研发

3、开放Open API,不什么都自己搞(时间长/质量差/成本高),而是采取接口方式外暴接入,让各种专业的供应商提供他们最优秀的应用

四、简化ERP选型评估购买:
1、免费网上在线试用

2、按功能点按使用人数按使用容量流量购买、随时充值、随时自动扩展,后台自动给各个应用提供商进行计费、分成、划拨

五、简化ERP实施:
1、安装部署:SaaS托管,自动安装部署

2、初始配置:预置典型模板,简化应用初始化配置

3、数据管理:提供数据清洗/转换/导入/校验工具

4、培训管理:网上文档/网上培训、网上社区问答/搜索

5、切换上线:自动化工具从测试沙箱环境切换到正式环境

六、简化ERP定制开发:
1、集成开发:提供数据同步集成工具/数据备份工具/数据导出工具、提供平台引擎的对外集成Open API接口

2、功能开发:提供新功能点开发工具、提供旧功能点修改工具、提供补丁包打包/安装工具给开发人员用

3、功能微调:提供UI微调工具给客户IT部门/软件公司实施人员服务人员使用

七、简化ERP运维:
1、基础软硬件:托管到云服务商,让云服务商负责基础系统软硬件的运维监控/优化/问题查找支持解决、扩展/迁移、升级

2、技术支持:内置日志监控点/收集点,进行日志跟踪/存储/传输/统计分析,便于问题根源快速定位问题快速修复
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/21620021
版权声明:本文为博主原创文章,转载请附上博文链接!

未来就在眼前 - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(1405)

来源: 未来就在眼前 – 阿朱=行业趋势+开发管理+架构 – CSDN博客

我写了多篇关于未来企业的文章,有很多朋友看了说这个未来很梦幻,但未来到底有多远?是三年?五年还是十年还是更远?三年我就动、五年我就看看、十年我就等等。

我今天给大家分享一个很成熟的企业的管理体系,这个企业我就不点名了,这个企业目前规模也非常大,年度营收也很大,但我仍然觉得它是敏捷的,它的管理体系是代表未来的、有未来的(所以敏捷和企业大中小无关),它应该就是现实的未来企业,这样的现实性、真实性,它是可以让大家复用的而不是只能赞叹(经常会听到XXX学不会),所以值得大家思考和借鉴。

一、产权治理结构

1、股权:这家企业是民企,创始人亲自创立,但创始人很早就主动缩小自己股权,把股份分给骨干员工,又引入外部独立董事、引入第三方投资、推动公司上市、严格遵守财务透明和财务规范,不炒作股市题材、不受股东急功近利利润期望的牵制匆匆前行或到处拿地/并购。我国很多上市企业一上市就成为了钱的奴隶,不去把资金投入到企业主业,而是到处投资多业经营、并购大大大再大、政府关系拿地搞XX园、股市放风炒题材拉股价。

2、钱:不仅股权让骨干员工有持续的未来的钱、无后顾之忧、踏实、共命运,而且在现金薪水方面也不吝啬,薪水几百万的都有。

3、权:该企业是诸侯制,每个地区都有独当一面、有很大决策权力和经营权力的诸侯霸主

大量企业口口说以人为本、一到实际行动需要利益投入立刻软蛋犹豫,这就是为什么有些标杆企业只能赞叹而无法学会,因为涉及到利益,谁敢大舍大得。大多数企业主都是凡夫俗子,赚一个亿的时候还想赚两个亿。真是生产关系决定生产力。所以经常会听到企业员工一句话:这关我屌事,多一事不如少一事。

二、制度流程

很多企业老板担心这样的企业这样的人怎么管啊,这些诸侯会不会造反失控。这让我想起任正非和柳传志的一段对话。柳传志问你在华为只占这么小股份,其他人联合起来推翻你,你怎么办?任正非说如果有一天人们联合起来要推翻我,说明我自身已经有了限制已经开始阻碍了企业的发展、企业已经不再需要我了,那说明企业已经成熟了长大了,我愿意离开。

而我说的这家企业给各地诸侯这么多的股份、钱、权,却也有配套的笼络。也就是说,给你好吃,但也给你高要求,你达不到高要求就必须把你踢出去。这就是繁华富贵也只在一线之间,你必须时时努力向前而不是躺在过去功劳上讲我没有功劳还有苦劳,我二十来年跟着你…。

这家企业从一开始就贯彻的是职业经理人制度和职业经理人风气,就连创始人都把自己定位成职业经理人,企业上市了长大了股权分散了企业就不属于创始人了,企业应该就是公众的企业,就要遵照公众公司来运作。

所以该企业制度流程建设非常盛行,做各种事都有机制、框架、组织流程制度、方法、工具。学标杆、引入各种西方现代企业管理工具,严格执行力。

该企业有专门的流程改进部门、流程改进委员会。流程改进委员会由流程改进部门与公司各业务线的管理梯队组成。流程的衔接讨论、制定、培训、落地执行、改进都是各业务线的各层管理梯队人员的份内之事,是在岗位职责说明中明确规定的,而且流程效率提升是所有管理人员的年度绩效指标。

流程改进部门是独立的部门,不属于业务部门,也不归业务经理领导。流程改进部门直接从属CEO/COO,直接向CEO/COO汇报。流程改进部门主要领衔流程改进会议/聚合各个业务部门、平时坐到各业务部门工作区并参加业务部门日常事物会议旁听来监督流程的执行落地、对各业务线管理人员的流程效率提升/流程落地推进执行的年度绩效指标进行评价考核。这就形成相互制约。

三、体系建设

该企业非常注重标准化建设。把客户按年龄阶段/生命周期进行分类,针对性设计标准化的产品。

有了标准化的产品,就容易有标准化的原材料供应商。所以他们又建设了标准化的供应商合作伙伴体系。他们有一套标准考核体系、合作伙伴流程、供应商共享工作IT平台,优胜劣汰大浪淘沙不断持续改进形成稳定的合作伙伴体系。这样的基础就形成产品生产效率高、质量高、成本低、可以快速复制扩张。

他们也建设了下游分销渠道体系。有自己的自营渠道,也有大量的代理分销渠道。这样的渠道结构才是健康平衡的。当然他们有很健康的利益平衡的自营渠道与代理分销渠道的竞争与合作的边界。他们对于自营渠道与代理分销渠道是同样的标准进入门槛、同样的协作流程与IT平台、同样的业绩考核,并没有厚此薄彼。

他们还建设了健康结构的现金流平台,让现金流健康弹性,现金多了浪费而且有融资成本,现金少了容易形成资金链断裂风险,而且资金来源必须多样化防止单一绑定引发连带风险。他们还专门上线资金管理IT系统,对资金池存量、资金流动速度、资金预算、资金申请发放、资金实际使用审计进行全程管理。

他们全国各处都有线下落地的服务团队,他们的服务团队的定位是客户关系持续维系与客户口碑,这是他们的定位,所以他们的组织岗位职责、服务产品服务定价、服务流程、岗位绩效考核与奖罚激励,都和客户关系维系/客户口碑主力相关。

他们的客服中心却都集中在总部不在各地分散,他们的客服中心属于CEO/COO直接管理与汇报。上游的研发、生产、销售、服务都可以把问题偷偷放水到下游,但客服是最后一个环节退无可退,所以他们把客服当作上游问题的曝光窗口、反向监察/考核的部门。只要接到客户的不满意,他们就反向到上游追查问题,事实证明确实是上游某个环节的问题就对该环节的关键责任人员进行绩效消减。对于绩效低于标准的合作伙伴或责任人就被踢出体系。所以该企业的客户满意度确实高于其他同行企业。这就是机制制约平衡的力量。

以客户为中心,这是大量企业都在强调的,但就是做不到,就是因为组织职责、流程、绩效考核都不是以客户满意为中心与目标追求的。

四、人力资源

该企业对人力资源建设非常重视,有非常成熟的培训组织、培训课程体系、岗位任职资格考核体系。

对于管理梯队,有很明确且成熟的继任计划、管理梯队培养组织、课程体系、日常工作辅助指导培养动作与要求、以及绩效考核。

对于员工层,他们是全国统一计划招聘、统一HR团队来负责招聘面试/评测、统一入职培训。

五、组织分工

作为一家全国性公司,组织建设最关键的就是总部和各地诸侯的关系边界。

该企业的总部明确划分自己边界,总部主要管理以下九方面:
1、标准核心产品研发(标准外的非核心的产品创新探索由各地自己决策)、标准核心产品的供应商合作伙伴体系建设、标准核心产品下游分销合作伙伴体系建设

2、各业务制度流程建设(流程改进部门和流程改进委员会)

3、各诸侯的年度绩效目标、绩效考核标准的制定与阶段性检查汇报

4、各地项目立项。他们有很明确的项目立项流程、立项标准、评审组织、评审标准。不是某个大佬一拍板就干。以项目管理为中心,以项目集结/归集所有资金、人力、材料、流程、绩效。

5、资金平台建设,以及各地项目需要的资金预算、资金申请审批发放、资金审计

6、各地项目领军管理骨干团队的选拔、任命、调用转岗、辞退

7、人力资源统一招聘、培训、企业文化建设引导

8、集中客服中心

9、主干IT平台(门户/信息共享、财务/资金/会计、人力资源管理/绩效管理、战略管理/项目管理、供应商合作伙伴管理/分销合作伙伴管理/服务管理、客服管理)

六、IT建设

我为什么要把IT建设也当作管理体系的一部分,这对很多企业管理人员不明白。我洞察的是:IT技术已经是管理技术,就如同管理工具(如杜邦财务分析法、平衡计分卡、五力竞争模型等等)一样。管理的终极目标就是制度要求扎实执行落地、业务流程整合共享协作、检查监控风险,而IT技术与自动化技术恰恰也能达到此终极目标。

1、IT组织:该企业IT人员很少,也没有IT专家,也没有项目经理专家。该企业的IT组织主要是把IT合作伙伴、IT部门、企业业务不同进行协同整合,一起推进。制定标准、流程、验收考核是重心。对于IT规划,主要引入IT咨询合作伙伴与IT合作伙伴、业务部门一起讨论。对于IT实施、IT定制开发都由IT合作伙伴公司来主力负责。对于IT日常运维则外包给国际专业IT运维服务商

2、IT系统:由于该企业的研发、生产、原料供应、分销甚至服务都是合作伙伴生态链,讲究的是平台/标准/协同,不讲究自己全部做全部自己控制,所以其IT系统也是如此。每一块只找业界最优秀的,而不力求整合/大一统/纯净。所以该企业的IT模块颇为多样、松散,各个IT系统之间通过SOA/企业IT服务总线进行统一调度,而不是各个IT系统之间直接调用。需要业务打通的地方,他们就把关联的IT合作伙伴、IT咨询合作伙伴都叫来,一起制定数据标准、标准调用接口、标准传输协议,然后再企业IT服务总线上实现。该企业的业务本身就是产业链合作导向,所以其业务也本身就具有松散性,所以其IT系统正好也匹配松散,无须强关联强整合,这就业务和IT一致了。

七、创新

1、创新激励:该企业非常讲究以客户为中心,大量岗位都有客户满意的绩效指标,能让客户直接评价的就让客户评价,是内部岗位就让下游评价(所谓的内部客户)。导向鼓励微创新、而且着重服务性创新,只要能让客户称赞的都算创新。当月奖励现金、部门月度回顾会议上进行表扬,有普遍推广价值的就吸收进标准流程改进中、在企业文化月刊中宣传传播、让创新当事人到各地演讲培训指导。

2、服务性创新产品:该企业一开始的核心竞争力是设计产品/生产产品/卖产品,现在的核心竞争力是标准建设/合作伙伴产业链建设与管理/平台建设,现在服务性创新越来越多,产品的毛利在不断下降,而服务性产品不断增加,而且服务性产品主要靠产业链合作伙伴提供,这样销售收入主体/利润主体就靠合作伙伴来提供了,而企业真正成为一家平台型企业了,就从产业链中直接赚钱了,赚的就是整合收入。

八、最后总结

我为什么说这样的企业管理体系是有现实未来的、是敏捷的,是因为我个人判断一个管理体系是否好或不好,有两个基本原则:
1、管理必须为企业经营增值而支撑,否则少干

2、管理好我有一个判断准则:是否能对环境快速变化做出敏锐的反应,在危机时快速调整适应(或收缩或顺利转型),在大风来临时高速扩张还不崩溃

从这两个基本原则来看,该企业的核心是领导/标准/平台/产业链,人们常说一流的公司建标准,因为标准的本质就是规则,谁掌握游戏规则谁就能主导整个游戏。

因为该企业掌握标准/产业链,所以它可以根据市场环境的变化而不断变化伸缩,它没有自己很重的资产与包袱,所以它的扩张也非常快,它的收缩也不会像重资产企业那么痛苦那么利益冲突那么慢。因为它的服务公司的定位就是零距离持续维系客户关系/客户口碑,所以它紧紧抓住客户,谁挟客户谁就号令天下。它的创新导向多偏重服务性创新,所以众多服务型产品也使客户黏性极高。

这样的企业管理体系是幻想吗?是不现实的吗?这样的企业敏捷吗?这样的企业是不是代表未来?这样的未来真是遥不可及吗?
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/20770739
版权声明:本文为博主原创文章,转载请附上博文链接!

从IT匹配业务如何走向IT引领业务 - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(1370)

来源: 从IT匹配业务如何走向IT引领业务 – 阿朱=行业趋势+开发管理+架构 – CSDN博客

从IT匹配业务如何走向IT引领业务

一、IT规划的误区

有朋友做CIO,要出IT规划。之前准备了许多,梳理了现状组织/岗位/职责、梳理了现状流程、梳理了现状IT系统建设/IT接口建设/数据标准建设,然后总结好现状的业务与IT结合的问题与空白建设,做了一份从IT组织流程建设、IT系统硬件基础设施建设、数据标准建设、IT整合建设、空白IT应用建设、优化IT应用建设的IT规划PPT。而且这个PPT还有里程碑,一期期一阶段一阶段的建设、推广、夯实,居然要长达3年建设才能完成。

他问我这份IT规划做的怎么样?我问了一个一下子就点到他的死穴的问题:你们企业的3年战略规划给我看一下。

答案是没有。只有一个愿景,比如3年后上市、3年后年销售额要XXXX。但这个目标具体分三年该怎么一步步里程碑到达?没有。

我就说你们公司连3年战略规划都没有,你怎么就有了匹配你们公司未来3年的IT规划?而且凭啥3年后销售额要达到XXXX要上市?未来3年政府、资本、行业会有哪些潜在变化?这个问题该哪个部门来回答?在这种大背景下,竞争对手会怎么调整?这个问题该哪个部门来回答?在这种大格局下,自己企业怎么调整?这个问题该哪个部门来回答?在自己企业这种预期战略规划下,IT应该如何调整匹配?

这一连串问题,都傻了。朋友问我在这种啥也不清楚的现状下该怎么做IT规划。

二、CIO的最终使命

我说为啥不清楚这些现状?为啥老板做不出3年战略规划?就是因为没有这些信息支撑。为啥没有这些信息?就是因为没有明确负责这些这些信息收集、整理、分析的组织(人),没有有效的收集、整理、分析工具。

谁是首席信息官(CIO的直译)?首席信息官的使命就是为企业经营管理收集有效有价值的信息并整理分析,首席信息官实施N多IT工具系统,这是手段,目的是收集、整理、分析业务信息,为了支撑企业经营决策、管理决策。我这就是从最终目标来反向寻找手段的思维导向,你之前的IT规划是现状怎样我就怎样,你就是把现实EXCEL/纸张业务翻版到了软件而已,你还规划了三年才能建设完毕,你这简直就是拿现状情况来定义未来,这种思维怎么能适应未来的变化与竞争速度?

三、循序渐进从匹配到引领

既然认清了收集、整理、分析企业经营信息企业管理信息的责任人和组织,既然认清了收集信息的最终目标是为了支撑企业经营决策、管理决策,那么我们正确应该怎么做呢?怎么从IT匹配业务一步步进化到IT推动业务、IT变革业务、IT引领业务呢?

1、IT匹配业务

IT匹配业务这个起点最容易出理解偏差,很多CIO都当作E化了,反正手里有个IT工具锤子,发现哪块业务没有E化就给它上个IT系统。我说这样IT匹配业务是不对的。

我们要反复的说,我们的使命是利用IT工具的便捷/自动化来低成本的有效的收集整理分析有助于企业经营决策企业管理决策的信息。我们不要什么信息都收集。加快企业岗位效率/岗位间效率/部门间/业务线间/区域和总部间的业务协作效率、信息一查到底/全程回溯、制度要求固化/统一执行,这些都是IT工具的本身优点,你只要上一块IT工具就会自然带这些优点。但我们就为了这些优点而去上一个IT系统,我们还得为了支撑我们的企业经营和管理啊,这才是企业IT的威力价值,这才是为企业增值、是老板所倚重的。所以我们需要一直围绕这个核心打。

所以先把和企业经营密切相关的业务进行E化了,到此为止,不要再过了。因为我们马上就要进入下一阶段就是IT推动业务,而非全面E化。

2、IT推动业务

要想IT推动业务,就需要把业务问题用IT的手段暴露出来,而且要考虑什么方面的问题暴露给什么层次的什么人。IT部门为啥老推不动业务部门?就是业务部门觉得没啥大问题、能完成业绩就行了。很多业务部门说我天天做业务,问题我还不了解?但真的拿出数据来说,发现自己的感觉和事实并不符合。把问题暴露出来,用数据事实证明说话,这无疑就是后面有人踢屁股。所以业务的决策问题、风险识别问题、风险管控预警问题、业务结果绩效衡量问题,这都需要IT来暴露。不了解真相,下的决策都是偏差而无效的,这既消耗了时机和资源又打击了士气。

只要业务部门人们都开始动起来,你就化被动为主动了。用收集来的事实数据来下决策、来做计划、来推动执行、来管控、来汇报、来优化。这样业务该怎么走怎么变,都是主要拿IT信息来做支撑了。

3、IT变革业务

咱们先说说啥叫业务变革,然后再说IT怎么引发、主导、控制、完成业务变革。业务变革包含:企业经营的新业务开辟、企业经营的现有业务的卖掉或萎缩、企业经营的现有业务的重大变化。

开辟可能需要成立新的组织、新的流程、新的股权与资本、新的权责与绩效。应该开展什么样的新业务,应该怎么变革(拆分、并购、控股)、应该怎么推进,各个阶段需要什么样的信息支撑?

卖掉、萎缩、重大变革也类似此思路。一般做此重大企业举动时都是高管层好多人开会、讨论,如果没有用于决策的关键信息和准确信息,这些开会讨论无疑就是在靠经验拍、博弈、捧老板唯老板适从。现实中有很多例子就是企业开展了新业务发现并如之前拍板想象的好,这就是缺乏信息。谁能快速的、全面的、精准的收集到决策讨论需要的信息,谁就胜出。IT技术就是CIO很好的一把刀,业务的变革可能需要CEO或业务老大亲自操刀,但CIO可以给他们提供很好的信息工具,也可以直接给他们输送有价值的决策信息。

但是我们也要反思,我们CIO真有额外的技术优势么?当我们真要收集、整理、分析这些信息时,我们真的能拿出更有效率更高价值的IT工具么?反思这个问题,会让许多以为自己拥有技术能力的CIO大汗淋淋。

4、IT引领业务

企业的使命在于创造市场客户、创造产品、营销。这是企业经营的核心内容。所以在这个阶段的IT成熟度,你就可以利用IT数据+IT互联技术来整合产业链、整合客户、整合研发生产,把企业内外都打通,让所有链条相关者在一个信息平台上一起协同,一起创造市场、创造产品、营销、销售。为什么我们把电商开展、SNS开展当作IT引领业务的典型案例来看待呢,因为电商本质就是企业和消费者的直接销售打通,而SNS是企业和消费者关系的直接打通与持续维系。这显然就是IT引领业务了。
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/22199313
版权声明:本文为博主原创文章,转载请附上博文链接!

我们到底在定制什么 - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(880)

来源: 我们到底在定制什么 – 阿朱=行业趋势+开发管理+架构 – CSDN博客

我们到底在定制什么

谈企业信息化,二次开发是避免不了的。关于二次开发的费用、进度、质量都是大家吐槽的问题。但大家或许没有总结过、当然由于定制大多为软件商黑箱所以也不好分析,所以虽吐槽但也无可奈何。

我是出身软件商,既做过研发最高领导人,每周还有个雷打不动的动作就是:过费用/计划/质量超标的项目、代码复查/BUG分析。通过这些项目分析/代码分析/BUG分析来反推是我们软件研发内部哪里出了问题:是人能力不行?架构问题?工具模板问题?上下游前后台协作问题?寻找问题根源以打七寸。

问题分析多了日子久了就发现很多问题是一而再再而三的,都有规律和分类,我们只不过是在原地绕圈而以。那我今天作为深喉就给大家揭露揭露,大家也对照对照自己之前提过的二次开发需求看看是不是我说的这么回事。

一、查询统计类

这是我们最常见的二次开发需求。这里面出的最多的问题就是口径不一致/计算公式不一致。客户提A就修改A,发现B报表也有这个信息,但B报表没提我就不修改。发现了就再提需求再改。

查询统计类还常见的问题就是用原始业务数据做综合统计报表。这不仅影响业务生产系统的性能,而且统计报表不稳定,经常受业务系统的特殊业务操作而篡改历史数据(撤销、反结、负退)等等。所以搞综合统计报表我们的正道是用商业智能的技术。但很多CIO一提商业智能就头大,而且要新购买一个系统,就想凑合。CIO凑合,定制开发人员也跟着凑合,有的综合统计报表写了500行SQL(性能又问题而且再修改还不好修改出了错误还不好调试),有的综合统计报表干脆用SQL写不出来的(程序员用代码+SQL混合搞个报表功能)。

二、性能调整类

由于产品开发时、定制开发时都有限的人力有限的时间赶着做业务功能了,这些性能啊、兼容性啊、可集成性啊、安全性啊等非功能要求都没人管了。数据量一上来/用户一多了性能就有了问题。所以哪个功能点有性能问题就优化哪块。等后来优化了A然后B就慢了,优化了B连带C就莫名其妙慢了的时候,这样修改就不行了,又得从架构整盘考虑了,这就小问题积累成大工程了,这又是一次大的定制优化项目。

有的性能调整还不是动动参数改改索引这么简单的,有时需要复杂的负载均衡、查询分离这些架构级的大方案。但你购买的那个版本的平台不支持这些特性,那就又是大定制啊。

三、移植类
1、把A客户曾经提过的需求定制过的代码,在B客户处再改一次,因为B提的需求和A提的需求差不多,但B客户并不知道之前已经开发过了

2、把高版本产品中的某些业务功能移植到客户当前版本

四、对外集成类

对外集成需要有这几个层面的集成:门户集成、业务逻辑算法集成、工作流引擎集成、消息引擎集成、主数据集成、数据同步分发。但经常会出现的是:平台提供的某些集成技术不支持、没有对外集成接口/没有支持多种主流集成技术。所以要集成,只能修改平台、再升级平台,升级平台还得考虑上面所有子系统的兼容性,这就工程量大了去了,想起这样搞就觉得风险极大。

为了防止风险被憋大,所以很多CIO在IT建设中期就开始选型独立的IT集成平台。但发现每个核心业务系统都有所谓的平台,但都不完善,而独立的IT集成平台和他们这些平台又不好整合,因为他们各自的业务系统和他们的平台绑的很死,所以还是N多平台共存,整体系统格局更复杂。

五、对内跨版本集成类

怎么还有个对内集成。这就说到了企业购买子系统(模块)是分年购买分年上线的,所以即使是同一个软件供应商,N个子系统也是不同的版本。要让不同版本的子系统还能连在一起流畅贯通,这就难了。因为有的新版本上确实有很好的功能特性是客户最需要的,但新版本的各个子系统也是业务模型完整体系的,要把其中一个新子系统抽出来给旧版本子系统配上,这有时连业务模型业务流程都走不通。这就如同要把杨贵妃的嘴、西施的眼非要堆在一个脸上一样。但这么离谱的事情居然我们很多CIO都在干。当然一番大修改了。

如果这个软件供应商平时就没怎么注意各个版本的业务模型向下兼容性、各个子系统的接口边界、以及接口的向下兼容性,那…,大家就知道定制开发工作量有多大了。

六、平台加固类

安全:这个东西是个一般看不见一般也不发生的事情,所以很多CIO是口头重视但在选型评分、日常运维方面都没有对安全做太多照顾。很多IT业务系统在研发时对安全架构并不看重,都奔着发布新功能去了。一旦说要加固系统安全,完,因为安全是遍布各层各个模块的,系统需要再很多层的关键口上加安全控制,所以一整安全项目也是大定制项目。

运维:很多平台光注重产品开发工具、定制开发工具的支持,对应用运维、技术运维没啥考虑。但系统上的时间长了,运维正规化就要提到日程上了。这样就需要加强平台对于应用运维技术运维的支撑,这还需要大定制,哪能那么容易给外围按个服务工具就行的。

七、功能完善类

有些子系统吧,虽然已经开发出品了许多年,但购买人少啊,所以磨合的人少。有的客户就购买了,一用发现还不成熟,这就改吧。

八、BUG类

1、项目BUG:很多BUG是出在了传递上。企业业务部门-企业IT部门-一线实施顾问-二次开发项目经理-二次开发系统设计员-二次开发程序员-测试人员-实施人员。很多需求经过讨论来讨论去、打回/完善/变更再到设计再到开发再到更新,这都多少道手了。这中间N多细节被漏掉/被扭曲理解了。只能发现一处修改一处

2、产品BUG:有的客户购买的是某一版本的子系统,新的版本已经修复了某些BUG,但客户的系统已经被定制修改过了,产品补丁包不能直接给客户升级了,那就不升级了(升级成本/升级风险)。直到客户发现了某个问题再修复,这又成了二次开发了。

3、数据BUG:有时候是客户业务部门录入的异常数据,有时候是EXCEL导入的异常数据,有时候是软件BUG引发的异常数据,要重新清洗数据、修正数据、校验数据,这都需要占开发工作量(其实这个活是技术运维部门的活)

九、攒出来的定制需求

怎么说是攒出来的呢?因为我们把定制开发高峰分为三个期:实施期、推广期、服务交接期。往往实施期要做业务流程梳理/需求调研/蓝图规划,在没有实际使用前总是只能指指点点提出一些零碎的需求,这些需求就会被集中开发一次。等试点实施过后要大面积推广了就会发现更多人的更多需求,这又会攒一批集中修改一次。等都上线使用了,这就要进入漫漫的持续运维期了,实施要和服务交接、客户一看实施结束了要撤场了就急了,于是最后一大波需求又来了。看似每个需求都不大,但需求攒起来就够设计/开发/测试个20多天。

所以我们软件公司内部也分两个团队,一个是专门做小需求小BUG修复小优化,一个组专门做重大修改。这样让小的需求交付快,让重大大范围修改保证稳定质量。

我作为CTO每月都进行定制需求工作量统计,发现小于2天的定制需求占了90%之多,即使是那些大的需求修改,那也是我上述说的一些重大方案(往往涉及到平台架构的调整或综合统计分析需求)。

十、反思

我说了这么多定制开发,你是不是发现你过去提的大量需求很多都在此范围内。

我其实想真正探讨的是:我们每个企业是否真的业务很个性很特殊?因为我从定制需求统计分析上来看,没看出多少真正业务上很特殊很个性的定制需求。这个问题很值得各位CIO深思。我们到底在定制什么呢?
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/22310227
版权声明:本文为博主原创文章,转载请附上博文链接!

云IT应用和下一代企业的关系 - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(1117)

来源: 云IT应用和下一代企业的关系 – 阿朱=行业趋势+开发管理+架构 – CSDN博客

一、云IT应用和现在IT的优劣势对比

1、安全:

从技术安全角度来说,公有云确实比咱们现在IT安全要更安全一些。为什么这么说?因为做云服务目前面临最大的客户迟疑就是安全,所以研发商在安全架构/安全编程/安全监控/安全应对方面投放了很多资源。而我们现在IT,很多企业的IT还是以局域网C/S应用为主,虽然也有不少企业应用了B/S应用,但都重重包围在VPN/U盾/域用户/指定IP之内,其本质就是仅仅利用物理广域网的局域网,所以在软件安全架构设计、软件安全运维、软件安全攻击危机应对方面都缺乏经验,尤其公共互联网会面临恶意DDoS,这种安全攻击应对更是很多企业IT部门没有见识过的。

但从国安、税务这两个中国特色来说,公有云比咱们现在IT形式更不安全。但现代信息社会手机社会移动互联网社会,信息的传播非常快,所以也反逼企业和政府越来越规范越来越透明,所以这个担心的企业会越来越少。

2、价格与质量:
从价格和服务质量来说,咱们按十年使用期综合总拥有性价比来看,公有云更好。公有云比现在实施/运维的效率、质量更高了。目前公有云成本这方面不好说,估计和现在IT差不多,但公有云好的一方面可以持续多年分期支付,不像现在IT需要一次性付几十万几百万那么压力大。
不过从服务质量要求来说,国内企业对IT依存度不高,所以服务质量好不好不敏感,但价格最敏感。

3、定制开发:
从定制开发来说,本质没区别,只是放你机房还是他机房的区别。为什么我会这样说呢?因为现在的云IT提供,都是给一个企业一套独立的软件环境,通过虚拟机在服务器集群中运行。现在虚拟机技术都进化的不像过去那么重型了,所以一台服务器也能放不少虚拟机。因为大家都是独立软件环境,所以什么定制开发/集成、备份/下载备份、升级/补丁安装都各自一套,不会受到其他企业的干扰,所以大家也根本不用担心数据隔离的问题。另外关于定制开发,大家可以再看我的一篇文章《我们到底在定制什么》再反思反思。

4、集成:
从集成调用/数据同步来说,走互联网带宽确实比同一个局域网内万兆网服务器间速度慢点。但你不要太担心这个问题。因为未来的云技术/云应用是给下一代企业应用的。下一代企业就是小团队、平台型、开放的、互联的企业,小团队讲究独立自主自驱动自决策,小团队内部高内聚/小团队之间低耦合,企业成为平台为小团队提供公共服务,不再讲究企业大一统/顶层设计/统筹安排,所以对现在咱们最看重的集成反而在未来并不重要。

二、云IT应用的真正企业经营价值

关键不是自己企业规模大、分支机构多、数据量大,就要建立自己的私有云。关键是,未来的企业是开放的企业,需要把消费者、渠道商、生产/仓储/物流合作伙伴、供应商、自己的员工,都要放在一个信息网络上打通、共同全程协作。

而且未来企业IT需要大量调用外部的技术引擎(如语音识别引擎、图像识别引擎、翻译引擎、搜索引擎),这些引擎技术门槛高不可能有提供商卖给你,能做的人也寥寥无几,而且这些引擎只有在社会大数据的训练下才能更加“聪明”,而且这些引擎所需要的运算能力和数据存取能力高的惊人,这根本不是你一家企业内部IT能够支撑和买单的,所以必须调用这些外部技术引擎。

另外未来企业IT需要大量调用外部的信息技术Open API(如微信、微博、支付宝、银行、税务、人力招聘和评测网站、地图、点评、社会商品统计信息、上市企业客户经营信息、行业信息)。

未来的企业IT软件供应商也不是自己独家研发,首先它要接入这么多外部引擎和外部信息,另外它也需要开放Open API供其他的IT商调用,不能它只能调用别人而不让别人调用它。再次,现在的企业IT软件供应商一家研发N个子系统,每个子系统都做的不好不坏,这根本跟不上客户逐年增长的要求。所以未来企业IT软件研发只能Open API开放出来,上层的具体应用谁能做好哪块就精心专心的做好哪块,企业客户看谁做的好就用谁的,后台系统会自动计费、分成、划拨。有人说现在云IT应用提供商不能这样,必须要买就买一套,不能挑模块买,我说这就是云IT应用商架构做的烂或者它不想这样盈利。

企业最关键的是经营,而经营需要的决策信息往往在整个社会和行业而不在你企业内部,所以你要竭力从外部获得市场信息以支撑经营。外部第一步就是自己的内外自己的上下游信息要贯通,这是自己最容易收集和控制的。第二步就逐步接入现在的社会开放信息平台中获得社会和行业信息。

大家认为现在的云IT应用都提供的很简单还不成熟。其实并不是简单,是我们企业自己把自己搞复杂了。本来目标主要想有限资源用来提升我们的企业业务价值,IT人和业务中层人却把IT想的天花乱坠什么都想让IT完成(其实IT优点就那几个,大家可看我过去的文章专门有描述)。本来IT很简单,就是被企业人为设置的层层信息屏蔽道道审批、特权给把功能搞复杂了。本来企业业务也很简单,但就是被企业强制要求的还不靠谱的但又要装模作样做的预算、目标成本、计划给搞复杂了。现在以及未来的企业竞争环境,要么一条路径是大量收集数据大量分析,运筹帷幄,把假设确实做扎实,可以做到算于庙堂;要么一条路径就像篮球足球队,多练个人扎实技能多练配合多实战比赛,根据场上每分每秒的变化及时组合敏捷快速腾挪躲闪。可惜现在大量的企业是数据既收集不了也没有能力分析,还装模作样做计划,还非要押着人按照计划走。可惜现在的大量企业配合不了也随机应变不了。所以大量的企业都是中庸的烂企业,市场行情好就大家都一起跟着增长,市场行情不好就看谁的干爹硬谁的储备干粮足。所以我说,只有具备外部数据收集能力分析能力、内部小团队组织、产业链协同的企业才能进化为下一代企业。

CIO也不要因为上公有云而担心什么失业问题。这个问题多可笑,就如同当年推IT时业务部门人担心失业一样。上了公有云后实施、运维更效率高质量好,CIO可以真正把目光与焦点放到企业价值思考上。我前几天也写过一篇文章叫《下一代CIO》,大家可以看历史文章,里面就介绍了上了云之后的CIO的职责和要求的变化,上了云后CIO的企业价值更高。

三、我为什么一直传播下一代企业和云IT应用

中国企业成长之路、中国企业IT成长之路很漫长。很小部分是能走想走的企业,大部分是不能走但想走的企业,绝大部分是不能走也不想走的企业。

企业信息化大家都知道,客户理念不变,不仅软件商在价格上/销售上难度很大,而且在企业的IT推广/IT应用/IT价值发挥上也阻碍很大。所以我写了一系列下一代企业的文章,也写了一系列如何正确做好现在IT的文章,还写了一些普及入门正确认识企业经营/管理/ERP/IT的文章。让能走想走的企业进化为下一代企业,让不能走但想走的企业做点改善提升,让不能走不想走的企业看看受点渗透影响,所以我能做的就是:普众生、渡有缘人。
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/22859299
版权声明:本文为博主原创文章,转载请附上博文链接!

内部OA - 阿朱=行业趋势+开发管理+架构 - CSDN博客

mikel阅读(1072)

来源: 内部OA – 阿朱=行业趋势+开发管理+架构 – CSDN博客

 

内部OA

我发现OA正在不断瓦解,一块块模块正在拆分独立,越做越专

当然,现在仍然有许多小公司需要一个什么都有但都很薄的在线SaaS租用

而且各块都在APP化、微信公众账号接入。

我把这些列出来的目的是:供大家寻找思路,单独做专。

一、公告
1、HR、财务、IT
2、各业务部门报喜
3、分享学习会公告

二、会议
1、会议室预定、通知/提醒
2、会议汇报文档、会议纪要
3、分享学习会、文档、现场照片、评论交流

三、活动
1、活动发布、分享转发、扫码关注
2、报名、通知、签到、人员统计/分析
3、现场照片、现场评论/在线提问、现场打分

4、投票/统计

5、抽奖
6、材料采购/审批、报销/审批

四、报销
1、出差申请、报销申请
2、团建报销
3、请假/申请、打卡

五、项目/任务
1、任务
2、文档、跟进报告
3、项目周报

六、工作日报周报
1、填报
2、主送、抄送
3、点评

七、学习
1、在线学习:电子书、视频
2、在线评测、在线考试

八、HR
1、在线调研
2、在线评测

九、分享交流
1、blog
2、问答

十、客服支持
1、咨询
2、需求建议
3、产品问题
4、投诉

十一、团队融合
1、BBS

十二、物资
1、物资需求提交

2、物资采购/申请/审批

3、物资入库、出库
4、物资查询、借阅

十三、销售
1、客户资料
2、跟进
3、需求线索
4、订单、合同
5、付款、回款

十四、平台
1、门户集成、Web桌面
2、消息、IM、邮箱
3、工作流集成、表单设计、ERP业务数据对接
4、BI、报表集成
———————
作者:david_lv
来源:CSDN
原文:https://blog.csdn.net/david_lv/article/details/39639117
版权声明:本文为博主原创文章,转载请附上博文链接!