企业挣钱跟小区店铺有类似逻辑

今天在填明年海外部门预算,以往都是敷衍了事,没有在意,这次专门看了具体条目,以及金额数量,才发现预算金额如此庞大,再加上idc成本,人员成本,场地费,税务,剩下的就没多少来。一直以为挣了好多好多,结果算上来净利润还是在百分之三十左右,虽然说对比其他行业来说,已经是一个非常不错的水平了,但对于之前没有详细算过账的感觉来说,一下就打破模糊的偏差认知了。

这个利润率,也是公司坚持投入了好多年,才逐步打平以至营收的。

具体办企业与小商店在底层逻辑上有哪些共同点呢。

一,最后的利润,都是钱经过层层漏斗,漏到最后能留下来的,才是最后到口袋的。哪一个环节没有做好控制,都容易入不敷出。每个环节的成本控制,都不可忽视。对于负责人或老板来说,对每个环节的成本支出必须做到了然于胸。

二,外部合作必不可少,不管是企业还是小商店,都只是经济环节中的某一环,都会有上下游合作方,对于软件公司来说,云平台、支付渠道、投流平台等都会涉及到与其他企业的利益分配。对于小商店来说,进货商、场地租金、营收工具等都需要花钱解决,商店本身只负责末端售卖。大家都是整条产业链中的一环,参与进来才是最重要的。

三,都会有成本,企业成本的量级大,有企业资金的支持,能挑动的市场也更大,蛋糕更大。小商店成本相对小,需要从自己的口袋支出,面向的市场相对更小。常说,有多大能耐干多大事,同样,有多少钱干多大事业,为何,因为差异事绝对数量上,而在相对比例上,其实是差不多的,庞大的资金光靠小商店是得到不到理想的利润回报的,金钱永不眠,拿不到利率的金钱,是死钱,是金钱掌握者无法接受的,在通货膨胀面前,就是亏本。

四,都有风险,且在相对比例上来讲,风险差别不大。

五,都要交税,最后进口袋之前,不能把这部分给遗漏了,这可是很大一笔。

六,都可以利用数字化的思维进行经营,用户对哪些商品感兴趣,市场正在流行什么,什么品类利润率最高,都需要创新试错,这些问题都是相通的,抬头看市场,低头研究用户,善于思考的经营者,会有相似的动作。

七,如何获客都是第一大要务,应该说,对于任何生意,获客都是最重要的事情,无法获客,就算是有最好的商品,也只能自嗨,无人买单,就只能自己买单了。

八,都需要考虑商品选择,是自己制作,还是从外部渠道获取,两种路径都是可选项,重要的是将赚钱的流程搭建起来,并且跑通,跑顺畅。

相似之处不少,同时,不同的点也是有的。

一,企业面临的市场更大,全球市场,影响的因素会多不少,在组织布局时,更考验全局掌控能力。小商店面临的市场固定,影响因素相对少,把控起来更简单。

二,企业分工更细,几乎没有人能一人清楚全局,能看全局的也是从大层面理解,面面俱到绝无可能,这点小商店老板却可以如数家珍,了然于胸。

三,企业既是商品的生产者,也是商品的售卖者,而小商店往往只是终端售卖者,当然,如若是像包子店、面店这类,也是商品的生产者兼售卖者。

总的来说,钱都是从扣出来的,并不是流水多少,就有多少进入口袋,能最后进口袋的,都是层层盘剥剩下的。

Read more

痛风带来的思考

昨晚一罐冰啤酒下去,睡觉时就感觉脚踝隐隐发作,果然早上起床直接下不来地。跟崴脚的感觉十分相似,无法行走,只能坐在一起上滑动,公司上班也去不了了,呆呆得躺在家里,下午疼痛感加剧,整个心思都在左脚的疼痛上,没有其他任何多余的精力去关注其他事情,而此刻的阳台,乃最美人间四月天,春日的微风吹拂着阳台的花儿,温暖的阳光抛洒下来,一切都如此惬意,而我却无心欣赏。 人在健康时,生活中有好多问题,但人在不健康时,生活中只剩一个问题。 我对这句话的理解更深刻了。人是健忘的,在疫情期间、在手术期间,这种感悟其实已经很深刻了,但是病情好转之后,人还是会被日常的琐碎、工作的烦扰搅乱心绪,没有专注的去享受生活本身的美好。 幸福的秘密在于,去享受我们所拥有的,而不是顽固的去追求所没有拥有的。阳光、草木、微风,都是幸福的玩意儿,应尽情的享受。 再等两天,脚完全恢复好了,身体健健康康后,我要以更轻盈的姿态去生活,不纠结他人的看法,不执着别人的认可,关注自己的能力,享受拥有的生后。 还有一个反省,针对咖啡、酒、烟,

By 李浩

设计模式之命令模式

命令模式将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象,命令模式也支持可撤销的操作。 来解析这个定义: 1. “将一个请求封装为一个对象”,请求原本是一个方法,现在要封装成一个对象,说明要新增类来完成。 2. “可以用不同的请求对客户进行参数化”,说明是将命令对象作为参数进行传递。 3. “队列”说明需要维护命令多个命令的列表队列。 4. “撤销”说明有命令对象有undo撤销方法。 命令模式在设计模式中,算是一个比较不好理解的模式,很重要的原因是不清楚设计意图,不清楚不用这个模式前有何问题,这个模式带了哪些好处,能解决什么问题。 上一篇状态模式中,看到了状态模式抽离的是状态(属性),向上提成状态对象。有了这个基础,再来理解命令模式就相对简单了。命令模式抽离的是行为(方法),向上提成命令对象。 两者都通过“对象化”来解耦和扩展系统,但解决的问题不同: * 状态模式:处理对象内部状态驱动的行为变化。 * 命令模式:处理行为请求的封装与调度。 💡智能家居遥控器,假设我们有一个智能家居遥控器,可以控制 灯(Light) 和

By 李浩

设计模式之状态模式

状态模式允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。 来解析这个定义: 1. “内部状态”表明对象内部有一个属性来表示状态。 2. “内部状态改变时改变它的行为,对象看起来好像修改了它的类”说明状态改变后对象的行为发生了非常大的变化,不像是同一类的行为。 从目前的分析中似乎无法推导出状态模式的类图结构。 从实际的例子出来,来看看状态模式是如何演进而来。 💡我们有一个文档审批系统,文档有以下状态和转换: 1. 草稿(Draft) → 提交 → 待审批(PendingReview) 2. 待审批 → 批准 → 已发布(Published) 3. 待审批 → 拒绝 → 草稿 4. 已发布 → 撤回 → 草稿 从直觉出发,会使用条件语句实现需求逻辑。 public class Document { private String state = "DRAFT"; // 初始状态为草稿 public void submit(

By 李浩

设计模式之代理模式

代理模式为另一个对象提供一个替身或占位符以控制对这个对象的访问。 解析这个定义: 1. “替身”表明在客户端看来,代理类与被代理类是同一类别,对客户端来说看上去没什么区别,依然能够满足诉求。如此可以看出代理类与被代理类来自同一个超类。 2. “控制对这个对象的访问”,能够控制访问,说明前提是能够访问,才能在访问之前做这个限制,即代理持有对真实对象的引用(或能创建它)。 当然可能会质疑,用继承的方式不是也能完成目标吗,用代理类去继承被代理类,然后重写方法,加入控制逻辑。但这违背了"组合优于继承"原则,代理类与被代理类强耦合。 💡我们要开发一个图片查看器,需求如下: 1. 图片加载开销大(从磁盘或网络加载耗时),希望首次显示时才加载(延迟加载)。 2. 某些图片需要权限校验,只有授权用户才能查看。 3. 客户端代码应统一接口,无需关心是直接加载图片还是通过代理。 // 1. 抽象接口(Subject) interface Image { void display(); } // 2. 真实对象(RealSubject)

By 李浩