|
据《环球邮报》报道，曾为大型企业客户开发应用程序的加拿大科技业领军者称，联邦政府对ArriveCan的5400万元标价，令人难以接受。他们解释说，根据经验，大多数应用程序的开发成本都不到100万元。
他们还质疑为什么政府不直接与一家加拿大应用程序开发商合作，而是与23个独立的承包商和数量不详的额外分包商合作。 科技投资银行家、INFOR金融集团创始人兼首席执行官Neil Selfe说：“我和加拿大科技界的人谈过，他们都很愤怒。” 《环球邮报》对ArriveCan应用程序相关联邦合同的分析发现，该应用程序今年的总支出将超过5400万元，是政府最近公布的支出的两倍多。 此外，调查还发现，在这款应用上接受联邦政府工作最多的渥太华地区公司GCstrategies，只有不到5名员工。 该公司告诉《环球邮报》，它正在与十几个政府部门合作，并通过超过75个分包商履行合同。然而，该公司和政府表示，由于联邦采购规则中的保密条款，不能透露分包商的身份。 该公司还开发了COVID Alert应用程序，用于帮助追踪密接者，但已被关闭。据报道，这款应用的标价为2000万元。 ArriveCan是供旅行者上传与COVID-19措施有关的强制性健康信息，之后扩大到允许用户在飞往加拿大前72小时内回答海关和移民问题。 加拿大边境服务局(CBSA)最初表示，有5家公司接到了开发该应用程序的合同，但后来透露，这项工作涉及27份合同，23家不同的公司。 负责CBSA的公共安全部长Marco Mendicino周四为ArriveCan的费用进行了辩护。 他说：“这是一个必要的工具，”现在它是自愿使用，将用于海关申报。“对于那些想要使用它的人来说，这是一项可以延续下去的投资。” Roach Capital的投资者Fahd Ananta曾在Snapchat和Shopify担任高级产品主管。他说，无法理解ArriveCan的价格是如何攀升到5400多万元的。 他说，以他的经验，为一个大公司客户开发一个应用程序的成本不会超过150万元，而且开发人员会在拿到这么大的合同后庆祝一番。 “这太离谱了，”他在接受采访时说。“在我看来，我认为他们被宰了。” 类似地，Apply Digital公司的首席执行官Gautam Lohia曾开发过许多应用程序，他告诉《环球邮报》，他的公司为全球机构开发了复杂的软件，与ArriveCan产品相当的成本都在7至8位数之间。 他在谈到ArriveCan时说：“我用过很多次，它并不复杂.。” “两年半的时间里，5400万的费用实在是太高了。” 周四，《环球邮报》采访了7位加拿大科技公司高管，询问他们对政府的价格和外包工作方式的看法。这七个人都表示，从技术角度来看，这款应用相对简单，成本不应该接近5400万元。 Richard Hyatt是一名企业家，他创立了几家科技公司，现任Candr的首席执行官，该公司为二维码的使用提供方便。他称ArriveCan应用程序“很糟糕”，并呼吁对成本为何攀升如此之高进行审查。“这说不通，”他说。 Lazer Technologies的联合创始人Zain Manji表示，政府的做法引发了很多关于其决策的问题。 他说：“在这款应用上的花费令人震惊，尤其是在开发资金和资金分配方面。” 总部位于多伦多的Rangle公司的首席执行官兼创始人Nick Van Weerdenburg说，他的公司很可能在不到一个月的时间里花25万元就开发出了这款应用。 “这是一个非常简单的应用程序，”他说。 他补充说，政府转向一家主要将工作外包给分包商的公司是“完全不可接受的”。大约有100家加拿大科技公司可以直接开发这款应用，成本要低得多。 Maverix Private Equity创始人兼管理合伙人、加拿大创新者委员会(Council of Canadian Innovators)联合创始人John Ruffolo表示，渥太华应该通过采购为加拿大科技行业提供更多支持。当一家加拿大公司主要依靠身份不明的分包商受雇时，无法保证工作留在加拿大。 他说：“为一款非常普通的应用支付这么高的费用似乎令人震惊。” 保守党议员、公共安全评论员Raquel Dancho在接受采访时表示，所有的疫情支出和合同都应该接受审计。这款应用一直被批评会在加美边境造成不满，很早就该废除。虽然9月30日起它不是强制性的，但Dancho说，应该放弃。 “继续这么昂贵的东西是不合适的，”她说。 新民主党议员Taylor Bachrach表示，自由党政府未能对ArriveCan的成本做到透明，而且一再选择通过外包“让私营企业致富”，而不是加强加拿大的公共服务。 |
Copyright © 1999 - 2025 by Sinoquebec Media Inc. All Rights Reserved 未经许可不得摘抄 | GMT-5, 2025-12-26 08:58 , Processed in 0.136456 second(s), 24 queries .
