NetSuite Founder on the End of ERP and What Comes Next

What needs to happen before AI agents can reliably complete work across the systems that run a business? In this episode of Tech Talks Daily, I welcome back Irfan Khan, Chief Product Officer for SAP Data & Analytics, to discuss the distance between a useful AI pilot and a dependable operational workflow. Our conversation begins with the autonomous enterprise and what that means for teams working across finance, procurement, supply chain and HR. Irfan explains why agents need a shared understanding of business activity, including the state of purchase orders and inventory, before coordination can produce a useful result. We discuss the data quality, permissions and governance questions that become harder to manage as deployments grow. Irfan also considers how leaders should measure AI performance. Generating additional content or consuming additional tokens tells us something about activity, but leaders still need to understand the effect on productivity, accuracy and the cost of completing work. He shares how SAP has approached developer experimentation and why teams need to become deliberate about which tasks benefit from AI consumption. The conversation also covers company memory, an initiative Irfan describes as a way to bring institutional process knowledge into agent workflows. We discuss how employee trust depends on the task, why order entry requires a different level of precision from a forecast, and how open architecture can preserve choices as models and infrastructure develop. Irfan then explains SAP's approach to connecting SAP and non-SAP data through SAP Business Data Cloud and the wider SAP Business AI Platform. For leaders assessing the next stage of their AI programs, the discussion offers practical questions about context, access, cost and the business outcomes they want to improve. You can find the resources discussed in the accompanying show notes at TechTalksNetwork.com. Where is your organization finding the biggest obstacle to operational AI, and what would help you move forward?

When AI makes writing code faster, how do you decide whether your team is building the right thing? In this episode of Tech Talks Daily, I speak with Johnny Halife, CTO at Southworks, about what happens to software engineering when code generation becomes easier but decisions still require experience. The pressure to deliver faster is familiar. The harder question is whether teams have the review capacity, testing processes, and deployment infrastructure to turn that extra output into useful software. Johnny describes a different way of directing AI coding agents. Engineers need to specify the outcome, define what finished work should look like, and provide checks that can show whether it meets the required standard. Constantly telling an assistant what to do next can keep a person busy without giving the system enough responsibility to complete a coherent piece of work. We discuss how to create tasks that are small enough to review and substantial enough to delegate. We also talk about context. Giving an AI system access to institutional knowledge sounds sensible, but adding every document to every conversation creates its own problems. Johnny describes borrowing from open source contribution practices, including README files, contribution guidelines, and records of architectural decisions. His approach combines an explanation of why the system works as it does with directions for finding additional information when needed. It is a useful way to think about onboarding an agent without expecting it to absorb the entire history of a business at once. The phrase human in the loop comes up frequently in AI discussions, so I ask what it should mean in practice. Johnny describes checks before work begins and a review of test results and other evidence at the end, supported by progress updates along the way. The person responsible needs to set expectations and assess the outcome. Being available for an alert is only one part of that responsibility. An unnamed streaming platform project provides a practical example. Johnny explains how Southworks developed the supporting process in stages, improving documentation, tests, and the infrastructure around the developer workflow. He reports a tenfold increase across requests, changes, and delivered value, although we do not have an independently verified measure or a detailed breakdown. His broader observation is that the same improvements made the environment easier for human engineers to understand and work in. Finally, we discuss hiring and professional development. Johnny values software and cloud knowledge, curiosity, clear writing, time management, and the judgment to choose between competing possibilities. AI can make experimentation quicker, but someone still needs to decide which experiment deserves attention and when to stop. I would love to hear how this compares with your own experience, so please share your thoughts. Where does work now wait in your engineering team, and how are you helping people make better decisions about what to build?

What happens behind the scenes when a cross-border payment uses stablecoins, and how much of that should the customer need to understand? In this episode of Tech Talks Daily, I speak with Shah Ramezani, co-founder and CEO of Noah, about the infrastructure that connects stablecoins to business payments. The discussion goes beyond the transfer itself to the practical work required to move between currencies, choose a route, verify identities, and reconcile the result. Shah starts with the friction he sees in correspondent banking and the opportunity for a different settlement layer. He explains how stablecoins can move quickly between participants and then connect to local payment methods at either end. His example of a payment from the United States to Argentina helps explain the choices involved, including whether the recipient wants local currency or a dollar-denominated stablecoin. It is an illustrative scenario rather than a named customer case or a universal comparison of costs and delivery times. I ask what makes that experience work technically. Shah breaks the process into liquidity, routing, compliance, settlement, and reconciliation. The available partner, customer type, destination, and pricing can all affect how a payment is handled. Noah's role, as he describes it, is to bring those components together so partners can connect without building every part themselves. Identity is another part of the conversation. Shah discusses know-your-customer and know-your-business checks, including arrangements in which partners rely on checks performed by Noah and receive the information they need. His account makes clear that reducing repeated document requests requires coordination among the organizations involved. It also raises questions about who is responsible for each step and how that responsibility changes across markets. One idea I found most interesting is that users may encounter stablecoin infrastructure without choosing to hold or handle stablecoins themselves. Shah describes payments in which the technology operates behind a familiar interface. For a business considering that approach, the useful comparison is the full payment journey, including conversion, local payout, support, and each participant's obligations. We also discuss banks' continuing role. Shah rejects the idea that they disappear and instead describes a different distribution of responsibilities across payment networks and financial institutions. The conversation gives listeners a way to consider how new settlement technology can coexist with established banking relationships. Trust and regulation remain part of that assessment. Shah argues that stronger regulation provides reassurance, while acknowledging the difficulty of serving customers across jurisdictions with different reporting obligations, identity requirements, and fraud patterns. His confidence in the market's direction is his perspective. It should not be read as a guarantee that every stablecoin, provider, or transaction carries the same protections. Finally, Shah discusses Noah's plans to broaden its capabilities and invest in product development and hiring. He describes an opportunity to make the payment experience simpler and less complex for the user. For me, the accompanying question is how providers make their responsibilities clear when the underlying process spans several organizations. I would love to hear your thoughts, so please share your experiences. When you assess a new payment route, how do you weigh speed and cost against clarity about responsibility, access to funds, and help when something goes wrong?

What happens when the pressure to complete an ERP transformation leaves access governance waiting until after go-live? In this episode of Tech Talks Daily, I speak with Chris Radkowski, GRC Expert and Advisor at Pathlock, about the business consequences of access decisions. Chris previously spent 17 years at SAP and brings experience across access control, governance and security. We discuss why ERP risk belongs in transformation planning, with examples that connect system availability to manufacturing, incoming deliveries and the processes that keep a business operating. The conversation considers privileged access inside business applications. An identity does not need to administer a server to hold permissions that affect sensitive information, supplier records or financial transactions. Chris explains why the combinations of entitlements assigned to a person deserve attention, and how that assessment becomes more complicated as processes extend across several systems. AI agents and automated workflows add to the challenge when they can carry out transactions quickly or operate through credentials associated with a user. We also discuss the limits of scheduled access reviews. Chris describes the work involved in checking whether an inappropriate permission was used, including the manual effort that can arise when teams need to investigate historical transactions. He argues for combining access information with activity and transaction data, so teams can examine an unexpected pattern and initiate a review rather than waiting for the next certification cycle. For leaders planning an ERP or AI transformation, Chris recommends considering role design, access assignment, certification and emergency access early in the program. We discuss how changes between SAP ECC and S/4HANA can affect the permissions and transactions on which existing controls depend. Our conversation offers practical questions about who can act, what they actually do and how the organization responds when operations are under pressure. Which access decisions would you want resolved before your next go-live, and where are the gaps today? Please share your thoughts with me.

What happens when an organization restores its systems after an incident but employees still cannot connect to them? In this episode of Tech Talks Daily, I speak with Sterling Wilson, Global Field CTO for Business Continuity and Disaster Recovery at IGEL, about the endpoint recovery gap. Sterling explains why a laptop that is encrypted, unstable or being preserved for investigation can prevent work from resuming even when applications and infrastructure are available. We discuss why continuity planning needs to account for the device people use to reach those services. The conversation examines IGEL Emergency Mode, an administrator-led capability for supported IGEL Dual Boot-enabled endpoints. Sterling describes moving those devices into IGEL OS so employees can reach resources IT has approved while security teams continue investigating the Windows environment. He emphasizes that this is an alternative access path, rather than Windows repair, threat detection or a replacement for the wider incident response process. I ask how organizations should prioritize employees and services during a disruption. Sterling recommends making those decisions around business functions and dependencies rather than seniority, with the priorities established before a crisis. We also discuss who has authority to initiate a transition, whether people can still sign in and reach their applications, and how a team returns devices to its chosen operating state afterward. Sterling draws a distinction between a recovery time objective and the time it actually takes people to resume work. That brings the discussion back to testing, including scenarios where management systems, connectivity or other dependencies may be unavailable. For leaders assessing business resilience, the conversation offers a way to look beyond infrastructure status and examine whether the organization can deliver its services again. When did your team last test recovery from an employee's perspective, and what did it reveal? Please share your thoughts with me.